Catégorie : best practices

meilleures pratiques

une bonne préparation permet de réaliser de meilleures présentations dans les conférences

Le par mopertodans best practices, forum de discussion5 commentaires

Tout comme l’auteur du billet « Preparing to present at conferences », j’ai passé de nombreuses heures à regarder la nuque de présentateurs tandis qu’ils lisaient les points mentionnés sur leurs transparents projetés sur l’écran derrière eux.

En fait, je reconnais avoir commis cette erreur moi-même de nombreuses fois. Et, je ne pense pas avoir à en rougir. Personne ne m’avait appris dans notre système éducatif français de l’époque à réaliser des présentations, à prendre la parole en public et à transmettre des messages par ce moyen de communication. Cela a heureusement bien changé comme j’ai pu le constater avec mes filles et neveux qui ont l’opportunité dans leurs études supérieures de réaliser de nombreux travaux individuels et de groupe qui sont ensuite présentés à l’oral avec le support de transparents.

Bien que certainement moins expérimenté en la matière que l’auteur du billet mentionné ci-dessus, voici quelques points que personnellement je m’efforce de respecter:

  • Savoir exactement le message que j’aimerais que l’assistance retienne de la présentation. Ce que j’aimerais les voir faire ou changer suite à ma présentation.
  • Prendre le temps nécessaire à la préparation de la présentation. Même sur un sujet bien maîtrisé, il est important de bien préparer l’intervention, de bien analyser l’audience et l’objectif à atteindre, ainsi que les conditions physiques et matérielles de la présentation. Pour se faire, j’ai récemment réappris à ne pas me jeter sur Powerpoint d’entrée de jeu. Je commence par écrire sur papier ou sur tableau blanc le scenario, la trame de l’histoire que je souhaite raconter, la structure du propos, avant de réfléchir à comment le transmettre au mieux sous forme de transparents Powerpoint.
  • Éviter les transparents encombrés. La présentation n’est qu’un support au discours. Elle doit permettre à l’audience de mieux mémoriser certains éléments, en particulier grâce à des images et des illustrations frappantes. Dans le cas d’une présentation en personne face à une large audience, il n’est pas question de lire une liste de lignes de texte. Il faut transmettre une émotion, un message, une histoire que l’audience retiendra facilement et sur laquelle elle agira ensuite. Une présentation effective est une présentation dont on verra les effets comme le dirait encore aujourd’hui mon professeur de « Effective Meetings and Presentation Skills ».
  • Répéter, répéter, répéter… Le jour J, le discours doit être fluide. Aucune nécessité de lire les transparents pendant la présentation, ils ne sont qu’une illustration d’un discours que vous maîtrisez de A à Z. Vous avez également préparé des anecdotes et références à votre expérience personnelle pour donner vie aux points que vous allez aborder. Vous avez également essayé d’anticiper au mieux les questions, qui à les susciter vous-même si elles ne viennent pas spontanément.
  • Repérez la salle et les conditions matérielles de l’intervention à l’avance. Quel type de micro par exemple: statique (à bannir), micro-cravate, micro mobile. Cela va influencer, voire limiter votre capacité de mouvement. Il vaut mieux le savoir à l’avance. Défilement des transparents: commande à distance, opérateur (il faudra le préparer à l’avance), nécessité de retourner au PC pour passer au transparent suivant… Cela va influencer la dynamique de vos transparents et l’affichage progressif des transparents par exemple.
  • Si vous voulez utiliser du son ou de la vidéo pendant la présentation (une bonne idée qui dynamise les longues sessions), assurez-vous qu’ils passent bien dans la salle, au plan visuel et acoustique, et ce, même depuis le fond de la salle.
  • Préparer un papier d’accompagnement de la présentation au format Word, Acrobat ou un article sur le web, est une bonne idée. Signalez que ce document existe et où le trouver à l’audience en début de votre présentation pour qu’elle se focalise sur l’écoute de ce que vous avez à dire plutôt que d’essayer de tout noter.
  • Faire des recherches sur l’assistance ainsi que l’organisation qui vous donne l’opportunité de vous exprimer.
  • Fournir son pack de transparents à l’avance est également une bonne idée même si cela n’est pas expressément exigé par l’organisateur. Cela vous force à être prêt à 100% bien avant l’événement. A la relecture, quelques jours avant l’intervention, vous pourrez simplement revoir les exemples que vous comptez utiliser et les histoires à raconter en fonction de l’actualité du moment.
  • Prévoir un verre d’eau accessible pendant la présentation. Cela permet d’éviter d’avoir la gorge sèche et cela permet aussi de se poser quelques secondes pour réfléchir en cours de présentation.
  • Ne dépasser son temps de parole sous aucun prétexte est ma devise, en particulier si il y a d’autres présentateurs qui suivent.

Qu’ajouteriez-vous à ce début de liste ?

les secrets pour réussir une externalisation selon Prince2

Le par mopertodans best practices1 commentaire

Ces articles sur l’externalisation ou « outsourcing » m’ont paru intéressant car c’est un sujet peu souvent abordé auquel j’aimerais ajouter quelques commentaires basés sur mon expérience personnelle acquise lors de l’externalisation de l’informatique et du réseau interne d’un grand équimentier télécom dans les années 2000.

Secrets to Successful Outsourcing – Part 1 & Part 2

Quels sont les facteurs critiques à une opération d’externalisation et des partenariats  d’externalisation réussis Que ce soit pour des tâches simples ou d’énormes projets?

1. Préparation : On ne devrait pas voir l’externalisation comme la panacée instantanée à tous les maux opérationnels, financiers ou autres d’une société. Avant de nouer des liens avec un associé d’externalisation éligible, la société cliente doit entreprendre un processus décisionnel complexe. Les approches comme PRINCE2 et Managing Successful Programmes peuvent être utiles dans la décision de partir vers l’externalisation ou pas, de manager efficacement un projet externalisé, et cetera.

dilemne du core business2. Savoir-faire / compétence cœur de business : En règle générale, cela a du sens pour une société que d’externaliser des tâches répétitives ou spécialisées tout en conservant les fonctions fondamentales qui sont centrales et uniques à son business. Le calcul de la corrélation entre la capacité d’achever une tâche avec succès et sa valeur business peut aider à déterminer les secteurs qui devraient rester internes et ceux qui devraient être sous-traités.

3. Bonne gouvernance : On pourrait dire de l’établissement d’une structure de gouvernance et d’une équipe de direction expérimentée avec un comité de direction de projet que ce sont les pierres angulaires d’une externalisation réussie. La structure pourrait inclure, entre autres choses, le contrat et des processus d’exécution et apportera clarté et cohérence pour le fournisseur et le client.

4. Parties prenantes : Encourager l’implication et trouver la bonne balance entre les besoins de toutes les parties prenantes serait intelligent pour les garder à bord, tout particulièrement quand les parties prenantes incluent les investisseurs ou les actionnaires.

5. Buts et Objectifs : Déterminez quels besoins doivent être réalisés par l’externalisation et partagez avec tous les participants. Rappelez-vous qu’une tension commerciale normale qui existe entre un client et un fournisseur peut signifier que leurs buts et objectifs peuvent ne pas coïncider. Les clients veulent normalement payer le prix le plus bas possible pour la meilleure qualité; les vendeurs veulent normalement maximiser le revenu et minimiser des dépenses.

6. Compatibilité : les clients et les fournisseurs qui ont quelque chose en commun ont naturellement plus de probabilité de rester ensemble. Les différences en expertise, méthodologies, éthos, valeurs, pratiques de travail, langue et cultures : celles-ci sont certaines des choses à considérer pour établir s’il y a une bonne adéquation entre les deux parties. Par exemple, si un client et un vendeur utilisent la même approche – comme PRINCE2 – ils peuvent être sûrs sans tenir compte du composant qu’ils achèvent, qu’il se raccordera avec les autres parties du projet.

7. Processus de sélection de Fournisseur : l’Évaluation inclurait : le coût total, les bénéfices attendus, la stabilité financière, la capacité, la compétence, la fiabilité, les processus d’audit, le contrôle qualité, la localisation géographique et la taille, en classant les prétendants potentiels par rapport à ceux-ci. Cela vaut la peine de noter bien sûr que le fournisseur le plus bon marché n’est pas nécessairement le meilleur puisqu’il peut avoir conservé une trop faible marge d’erreur qui peut mener à des dépenses plus élevées, qui pourraient à leur tour être passées aux clients. Les accords de Niveau de Service, des Indicateurs Clefs d’Exécution et d’évaluation de performance jouent naturellement leur rôle à divers moments dans la vie du contrat d’externalisation.

8. Options d’Approvisionnement : En adoptant une approche flexible d’approvisionnement, les sociétés peuvent adapter la stratégie d’approvisionnement aux projets, aux services et aux circonstances. Une situation économique fragile peut faire paraître le multifournisseurs plus attractif que le fournisseur unique pour répartir le risque d’externalisation sur plusieurs fournisseurs; cependant, les risques tels que la perte possible d’intégration au travers de multiples projets et une pauvre gouvernance peuvent rendre cette option périlleuse. L’externalisation « intéressée » où clients et fournisseurs collaborent pour réaliser ensemble leurs buts et objectifs est une approche qui peut valoir la peine d’être examinée.

9. Contrats : un contrat solide est essentiel et les sociétés peuvent y couvrir un grand nombre de choses comme les rôles, les responsabilités, les garanties, les niveaux de service minimaux, les bonus, les pénalités, la propriété des données, les droits de propriété intellectuelle, etc. Intégrez de la flexibilité pour pouvoir faire les changements qui seraient nécessaires sur des projets à long terme et cela peut inclure l’option de poursuivre un Plan B ou de mettre en œuvre une stratégie de sortie de contrat. Finalement, considérez la possibilité de découper les grands projets ou grands contrats en de plus petits.

10. Transition : Formez une équipe des deux côtés de l’association pour gérer la transition, définissez les processus à suivre, définissez une ligne de temps et établissez les points de rencontres ou jalons qui matérialisent l’achèvement de chaque partie du processus de transition.

11. Communication : au cœur de toute externalisation réussie est la façon dont les sociétés sont connectées l’une avec l’autre et avec leurs parties prenantes, donc de bons canaux de communication sont essentiels. De bonnes relations client/fournisseur peuvent aider chaque côté à clarifier et comprendre les buts, rôles, responsabilités, progression du projet, développements de l’industrie, changements business et autres et peuvent en conséquence aider à créer la confiance entre toutes les parties.

12. Le Personnel Clef : Pour mieux contrôler vos projets d’externalisation, le personnel compétent clef pour contrôler la performance d’exécution de la société prestataire et prendre ces décisions clefs de management. Le moral du personnel peut aussi être accru par leur acquisition d’expertise du fournisseur pendant le processus d’externalisation qui peut à son tour permettre à la société de retenir les personnels clefs et les conserver plutôt que les externaliser sur des projets semblables à l’avenir.

13. Mesure de Résultats: une gamme de mesures rigoureuses mais significatives qui ne comptent pas excessivement sur des outils comme les Accords de Niveau de Service (Service Level Agreements: SLAs) ou des Indicateurs de Performance Clefs (Key Performance Indicators: KPIs), mais qui intègrent des évaluations qualitatives peuvent efficacement contrôler la performance du projet d’externalisation et voir s’il délivre ce que l’on a promis.

14. Risques : Toute relation apporte des risques et ils peuvent être coûteux : les projets peuvent être retardés ou échouer, les réputations peuvent être ternies, les données peuvent être perdues, la sécurité peut être contrevenue et bien plus de désastres dans la même veine pourraient atteindre de la même façon le fournisseur et le client. Les sociétés peuvent adopter des mesures comme des registres de risque et adopter des approches, telle que le Management des Risques, pour les aider à réduire leur exposition aux désastres potentiels.

15. Sécurité : l’accès aux données est un sujet sensible et la protection des données une priorité. Les clients doivent donc considérer leur responsabilité conformément aux lois de protection des données et s’assurer que les fournisseurs ont le stockage de données adéquat, le chiffrage, des coupe-feux(firewalls) et détection de fraudes et semblables.

Partenaire de DantotsuPM

10 false ideas about Agile Methods

Le par mopertodans agile, best practices, outils et méthodesLaisser un commentaire

For once, I decided to translate French articles for our English speaking readers and those of us based in France who work in an international context and would like to share these with our foreign colleagues.

The original articles (2 posts in fact) were published by Renaud Choné on the blog of his company, Time Performance: http://www.timeperformance.com/blog/16-generalites/101-5-idees-fausses-a-propos-des-methodes-agiles

The wide variety of agile methods and their practices generates numerous false ideas on this subject. The object of this article is to demystify the most common false ideas found in the debates on Web by answering these factually.

The arrival of the Agile Methods is generating a ditch between their partisans and those of traditional methods. This rupture is strengthened by the fact that 4 founding principles of the agile methods contradict directly the classic approach:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

( Cf. the Agile Manifesto, the official site: Http://agilemanifesto.org/)

The idea here is not to take position but to allow healthy debates. Indeed, at Time Performance, we are convinced that there is no good method for every situation. And it is moreover why our management of software projects was designed to be flexible while being inspired by the best practices and tools, agile or classic.

False Idea n°1: the Agile Methods apply only to « small » projects

False, forgery and ultra-false… It is nevertheless the most wide-spread idea. It is also the most false.

1) The reason for being of Agile Methods is to allow the project to adapt itself easily to the changes ( » Reponding to changes « ). It makes sense only for the projects of rather long duration, because the risk of change is strong all the more as the project goes on. Furthermore, the duration is necessary to take the full benefits of the heavy investments made in the tests, their automation and the quality of the code, which are at the heart of the agile methods.

Moreover the Agile methods were designed for the development of software products (hence the term of Product Owner which we find in SCRUM), for which the life cycle extends over several years or even several decades.

This false idea was maybe inspired by the brevity of the development cycles. And precisely, an iterative development aims at avoiding the risk of tunnel effect, which is important all the more as the project is long.

Thus the Agile methods are particularly adapted, even recommended, for long projects and not for the small ones.

2) Concerning the size of the team, it is true that SCRUM limits the size of the teams to 8 or 9 individuals, and XP recommends it in practice, because it is the optimal functioning. But nothing forbids establishing several teams which will work each on a sub-project. Moreover SCRUM embeds it with a coordination mechanism which is called the SCRUM of SCRUMs. A team of several dozens of persons can be so constituted.

False Idea n°2: the classification « Agile Method » determines a homogeneous group

The Agile methods are very different from one to another. They are even sometimes almost totally complementary, as XP and SCRUM. If these last 2 methods mark a real break with regard to the classic approach, some as Unified Process establish intermediate steps in the evolution of the methods during the last 20 years.

All these methods agree only on the 4 principles, that is little. Furthermore, the Agile Manifesto offers certain freedom in interpretation. It is thus risky to speak about Agile Methods generally. It is better to speak about practices proposed by such or such method.

On top, it is necessary to add that the implementations of these methods are even more heterogeneous.

False Idea n°3: the Agile Methods are methods of project management

Firstly, the object of the agile methods is software development and not the management of projects. If certain topics of project management are mentioned such as the estimates and the planning, others are plainly absent (for example costs management).

Secondly, the agile methods are not methods. The authors of XP and SCRUM define them as sets of good practices.

False Idea n°4: the Agile Methods are methods of rapid development or prototyping

Short cycles of delivery do not mean that the developments are rapid. It implies simply to validate the progress regularly and concretely.

There are even chances that the developments will be less fast at first with regard to a V cycle, because of the requirements in quality of code and tests coverage, including of numerous re-developments. It is not thus a good approach to use for prototyping.

The Agile projects are marathon runners and not short-distance runners. That is why they travel light. And on the distance, they are generally the fastest and consume less.

False Idea n°5: the agile developments are with difficult to maintain because of the lack of documentation

The fear of seeing the knowledge of the functioning of the software leaving with developers at the conclusion of the project is perfectly justifiable when the documentation is insufficient.

However it is an error to consider that there is no documentation. Following the example of Open Source, in an Agile approach, the main documentation is the source code. And as numerous deliveries are realized throughout the project, everything is made to guarantee a perfect maintainability.

On one hand, the coding rules are very strict and their validation is automated. Several practices at the heart of the Agile methods (the refactoring, the absence of Code Ownership, the Pair Programming etc.) guarantee in the end an appropriate, well designed, legible and well documented source code.

On the other hand, in the source code it is necessary to include the tests (unit, integration, functional etc.). The tests are similar to a document of detailed specifications and an integrated validation tool. It is a significant but indispensable investment for the maintainability and the evolution.

In an agile approach, the source code and the tests stand for respectively detailed design and detailed specification, expressed in natural language in comments and in IT language. The big advantage is to guarantee that the documentation is always up to date with regards to the code, and that the code corresponds to the specifications thanks to the daily tests execution and continuous integration. An agile development should thus be very easy to maintain.

Really, the true question is: « between a complete documentation (specification, analysis, design etc.) and an appropriate and well tested source code which would you choose? »

The agile methods give the priority to the source code and to the tests. The V cycle favors in practice the documents which are generated upstream in the project, to the detriment of the code and the tests situated downstream in the cycle when the pressure to go fast, too fast, is much stronger.

False Idea n°6: the Agile Methods, it is the freedom to do it its own way

Team in « self-management » mode, questioned project manager’s role, redistribution of the responsibilities, the abolition of the contractual aspects, no detailed planning, absence or almost of documents, mainly verbal communication…

All these elements which seduce the teams have a flavor of freedom and emancipation which will frighten more than a manager.

However it would be false to consider that the Agility is synonymic of absence of rules, constraints and structures.

The Agility is above all a change in priority, as demonstrate the 4 principles of the Agile Manifesto. With more distance, it is also a change in the nature of a project, the objectives of which are not any more the respect for a requirements book, at costs and on time.

Now all these changes rest on different organization models which have their own rules.

To be Agile, it is not enough not to apply the former rules, it is especially necessary to apply the new ones.

False Idea n°7: the Agility, it is simple thus it is easy

Following the example of a chess game, the rules of the Agility are simple but their application is not. Several years of practices are needed to master well the game.

The Agility is synonymic of lightness and simplicity. It is natural to see a promise of ease there.

This promise is confirmed by books on Agility. They are generally less thick and less heavy than their equivalents; the principles and the presented concepts are much less numerous and simpler.

To acquire the theory is thus easy, but what about the practice?

In practice, the Agile methods impose very strong requirements on the individuals and the organizations.

For the individuals, there is at first a requirement in technical skills to produce an evolutionary, quality and easy to maintain software, well tested etc. This does not apply only to the Agile methods. The difference is that it becomes a priority with the Agility.

For the individuals, there is then a requirement of behaving and personal discipline to collaborate, communicate, make a commitment, and demonstrate self discipline… It is very difficult to set up Pair Programming; and Daily Scrum can easily turn into chaos.

Some organizations would need almost reorganization. For example, to involve more the business in the development, to redefine the jobs (project manager, scrum master etc.) etc.

For organizations, there is also a problem of the lack of mid-term and long-term visibility with an impact on how projects are budgeted.

Finally, the Agility rests on a strong requirement of Transparency. It can have heavy implications for organizations and individuals. Ken Schwaber, co-author of the Scrum method, expresses with provocation a direct consequence of this transparency strengthened by fast feedbacks:  » [the Agility] expose  the incompetence « . Stated this way, it makes you think…

In practice, very few teams arrive at the end of an Agile step(initiative). But fortunately, the passage in the Suppleness can be gradually made with immediate gains (cf n°9).

False Idea n°8: the Agile Methods require senior developers

The requirements of Agility on the individuals (cf. N°7) lead to think that the agile methods are reserved for experimented teams, teams of champions of the development. This is exaggerated.

The minimum required by the Agility would be rather a team consisting of an experimented coach and open-minded individuals, capable of questioning, capable of learning and especially who want to progress.

With regard to other methods, an advantage of the agile methods is to facilitate the fast grow in skills of the team members.

How? Simply thanks to the very short iterative cycles which allow fast feedbacks on performance and improving for the following iteration. In SCRUM, it is institutionalized under the shape of a Retrospective at each iteration end.

Besides, practices such as the Pair Programming and the Daily Scrum facilitate largely the transmission of knowledge between the members of the project.

We can retain a principle: the less the team is experimented, the more the « Coach » owes to be.

False Idea n°9: incompatibility with the classic approaches

The agile methods propose practices which, taken separately, are not incompatible with the classic approaches (cascading cycle, CMMI, PMBoK etc.).

For example, it is possible in a cascading cycle to introduce Peer Programming, Retrospect, daily meetings, the Palnning Poker, Burndown charts, continuous integration, the Test Driven… Why not?

If there is incompatibility, it is not at the level of the practices, but rather at the level of the values.

False Idea n°10: the Agility can apply to anything and everything

When, to test its software, it was necessary to reserve several days in advance some machine processing time on the central server and print its software on punch cards, the Agility and its Test Driven and Continuous Integration would have made anyone laugh out loud

To be Agile, it is necessary to have the will but also the means.

In domains, as construction or industry *, the constraints certainly do not allow to be as agile as in the software development.

In a project at fixed price, a purely agile approach is inconceivable. It is inevitably necessary to fix the perimeter.

In a deployment project, the Agility may bring more inconveniences than advantages.

To be able to be Agile, the change has to be desirable but also possible at low-cost. That is why the software development is the privileged domain of the Agility.

* In the industry, there is a Lean Manufacturing. This approach shares some of the values and objectives of the Agility, but with different practices oriented towards the industry.

Be the Chinese doctor of your projects. Watch their vital signs.

Le par mopertodans best practices, forum de discussionLaisser un commentaire

I posted a new article on the Blog Orange Business Live.

As a Chinese doctor, who is paid to keep his clients in good health rather than to look after them when they are sick, the project manager has to follow the vital signs of his project, and to address them before it seriously gets sick.

  • Definition and implementation of concrete measures
  • Critical path
  • Respect for the schedule (variance of + or – 10 %)
  • Current efforts and results reached compared to plan
  • Projected costs and actual spend
  • Quality of the deliverables
  • Open Problems (number, time of resolution, age)
  • Periodicity of reviews
  • Management and control of the risks
  • Morale of the team and human aspects
  • Participation of the sponsor, involvement / satisfaction of the customer
  • Anticipation by the trend analysis of the indicators

Read the full article and let me know which other vital signs of projects should be watched.

why forcing unrealistic project dates is often counter productive

Le par mopertodans best practices, experience sharing, forum de discussion2 commentaires

It is not rare that project dates, in particular the end date, are forced on the project manager and his team. Are they realistic? How were they estimated and approved? What is their foundation?

Here are some ideas to better handle this somewhat frequent problem.

The arbitrary…

Let’s keep in mind the 3 parameters of projects: any project can be represented as a triangle which summits are time, costs and contents. To freeze or force one of the summits often implies sacrifices on one of the other two.

Thus, fixing a completion date in an arbitrary manner can lead the project team to try to reduce the contents (the scope) to fit the timeframe. It can also drive costs up with the use of more resources to reach by all means the time target either with more resources, or superior skills or more expensive ones due to time pressure (reduced negotiation position) or all three. Naturally, these changes should generate the necessary discussions with sponsors and stakeholders to reach an agreement. If the compulsory date is absolutely unrealistic, it is of the duty of the project manager to pull the alarm bell and even consider refusing the project (must read: « Code of Ethics and Professional Conduct » of  PMI).

On the sponsors’ side, it is necessary to be capable (I would even say that it is a duty) to explain the reasons behind the forced dates. These reasons can very well be valid and the project team, once it will have integrated them, will be motivated all the more to reach them.

A real life example was the implementation of a new accounting system at a big multinational firm. The sponsor of the team dedicated the necessary time to explain to all the stakeholders, project teams, future users, and management, the necessity of a launch of the new processes and application software on January 1st. Any delay would have caused big difficulties in data conversion and reconciliation at any other time during the year, i.e. additional pain for each person… The whole company was mobilized from then on; the deployment took place in time and was a success.

Rough estimates

There are many more or less scientific estimation techniques. The most wide-spread are the analog, parametric, intuitive methods or the experts’ advice, and « Bottom-Up ». Without going into too much details in this article, by analogy is about comparing a future project to similar already realized projects and extrapolating the estimates from this base. For example, if I have already implemented a software package in country X and I have to deploy the same product in country Y which of comparable size and complexity. I consider by analogy that the cost and the timeline for country Y will be sensibly the same as country X. The parametric method focuses at a high level at defining parameters that will allow estimating duration, efforts and costs. This is often used in Information Technology with parameters such as the number of screens, lines of code, interfaces between systems, and the other « Function Points » … The intuitive method is as its name indicates based on the personal appreciation of the estimator and it is mainly used to get quickly an order of magnitude. It is particularly useful upstream to prioritize approaches and downstream to identify potential incoherencies in the results produced by more detailed methods. The experts’ advices are often used to rationalize intuitive results. The experts draw from their experience and skills to provide their best estimates. Finally, the  » Bottom-Up » method, more analytical requires much more detailed work at the level the deliverables of the project to estimate efforts, duration and costs. Generally, it is implemented via the Work Breakdown Structure of the project (WBS), and we try to estimate at the lowest level possible.

The best is to apply to several methods and compare the results.

Involvement of the team and the project manager

For the project to be successful, we will need that the team understands and signs off for the dates, even if imposed, as well as the effort estimates… If we take the example of Scrum in the software industry, at the beginning of each code development iteration (the Sprint), the members of the team often have the possibility of choosing themselves in the list prioritized by the customer (« product backlog ») which they take the commitment to realize over the period. They are completely engaged from then on with the task and the duration.

At minimum, the project manager must be able to be confident that he dates can be held in order to motivate his team on the duration, contents and quality.

Realistic and reachable plans

Realists for whom? First of all for the project team. As mentioned above, the project manager and his team are going to have to answer in a positive way the following questions: Will we succeed in delivering a product or a service that we we will be proud of in the allotted time? What sacrifices will it require and are we ready for these? Will we get the necessary support from our sponsors?

Maintaining a completion date in spite of the delays to start

This case is regrettably very frequent. The supplied estimates are correct and the end of September was reachable with January 1st start of the project. But, here we are, on March 9, and over the past three months sponsors and stakeholders hesitated, asked additional questions, did not manage to find time slots to meet…  Finally, they saw each other this morning and agreed: we have the green light, this is great news! And (not as good) we are asked to respect the end of September completion and the budget!!! It will sound familiar to you, I am quite sure. However, unless we had inflated extravagantly our estimates (by 30 %) or are able to cut into the deliverables/contents, it will be mission impossible. Increasing the number of resources in such a drastic way at short notice does not seem plausible. One of the practices to be used to avoid as much as possible this type of situation is to include a milestone in the project’s critical path for the approval of the project (Project Approval Milestone – PAM).  Then, express the next dates only as a matter of delays from this milestone date. For example, the analysis will be ended 2 months after the PAM, the design 4 months, the construction 8 months and the phase of test 9 months (PAM + 9 Months). I know, not easy in practice, but it is worth trying it.

Involvement of the customer

Is the date really convenient for the end customer? For example, to deliver a new booking system for a hotel just before peak season is probably not an excellent idea. Maybe would it be better to wait for the following quiet season and to enrich the features, or on the contrary, to minimize functionality to the bare minimum and deliver the system much faster? Also, in accounting some periods are to be avoided to deploy novelties: balance sheets, month end closure, invoicing runs, the tax declarations … It is thus advisable to make sure upfront of the relevance of forced dates coming from sponsors and stakeholders and not to assume that they are fully aware of the customers’ impact.

Resources

For a reason and another, totally independent from your will, it was not possible to you to recruit the resources in time: order forms blocked in purchases, slow controls by the recruiters, delays by certain managers to give the required skills to the project… Nevertheless the sponsors and the stakeholders are not willing to accept any delay!

In fact, they are probably right. It is our job as PM to anticipate, avoid or surmount this type of obstacles and to call upon sponsors to help remove any roadblocks before the project is negatively impacted.

à propos des risques à vouloir imposer des dates irréalistes

Le par mopertodans best practices, forum de discussion3 commentaires

Il n’est pas rare que les dates du projet, en particulier celle de fin, soit imposées au chef de projet et à son équipe. Sont-elles réalistes? Comment ont-elles été estimées et agréées? Quel est leur fondement?

Voici quelques idées pour mieux appréhender ce problème somme toute très courant.

L’arbitraire…

Rappel des 3 paramètres: Tout projet s’inscrit dans un triangle dont les sommets sont le temps, les coûts et le contenu. Vouloir figer l’un des sommets implique souvent des sacrifices sur l’un ou l’autre des deux autres.

Donc, fixer une échéance calendaire de manière arbitraire peut amener l’équipe projet à essayer de réduire le contenu afin de tenir la date. Cela peut également conduire à un accroissement des coûts par l’utilisation de davantage de ressources pour atteindre à tout prix l’objectif de date ou bien des ressources de compétences supérieures ou de coûts plus importants. Bien sûr, ces deux alternatives généreront les discussions nécessaires avec sponsors et commanditaires pour arriver à un accord. Si la date imposée est absolument irréaliste, il est du devoir du chef de projet de tirer la sonnette d’alarme quitte à refuser le projet (voir le « Code of Ethics and Professional Conduct » de PMI ).

Coté sponsors et commanditaires, il faut être en mesure, et je dirais même se faire un devoir, d’expliquer le pourquoi de dates imposées. Ces raisons peuvent tout à fait être valides et l’équipe projet qui les aura intégrées sera d’autant plus motivée pour les atteindre.

Un exemple vécu fut la mise en place d’un nouveau système de comptabilité dans une grande entreprise internationale. Le sponsor de l’équipe avait pris le temps d’expliquer à l’ensemble des parties prenantes, équipes projet, futurs utilisateurs, et management, l’impératif d’un démarrage sur de nouveaux processus et applicatifs au 1er janvier. Tout retard aurait causé de grandes difficultés de reprise de l’existant pour l’année en cours, de travail supplémentaire pour chacun… L’ensemble de l’entreprise étant dès lors mobilisée, le déploiement se déroula dans les temps et fut un succès.

Estimations approximatives

Il existe de nombreuses techniques d’estimation plus ou moins scientifiques. Les plus répandues sont les méthodes analogique, paramétrique, intuitive ou avis d’experts, et « Bottom-Up ». Sans entrer dans les détails dans cet article, on estime par analogie en comparant un projet futur à des projets similaires déjà réalisés en extrapolant les estimations. Par exemple, si j’ai déjà implémenté un progiciel dans le pays X et je dois déployer ce même produit dans le pays Y qui de taille et complexité comparables. J’estime par analogie que le coût et les délais pour le pays Y seront sensiblement les mêmes que pour le pays X. La méthode paramétrique s’attache à un haut niveau à définir le ou les paramètres qui permettent d’estimer durée et coûts. Souvent utilisée dans le monde du développement logiciel avec des paramètres tels que le nombre d’écrans, de lignes de code, d’interfaces entre systèmes, et autres « Function Points »… La méthode intuitive est comme son nom l’indique basée sur l’appréciation personnelle de celui qui estime et elle sert principalement à donner un ordre de grandeur. Elle est particulièrement utile en amont pour prioriser les approches et en aval pour identifier des incohérences dans les résultats produits par des méthodes plus détaillées. Les avis d’experts sont souvent utilisés pour rationaliser les résultats intuitifs. Ce ou ces experts puisent dans leur expérience et compétences pour fournir des estimations les plus réalistes possible. Enfin, la méthode « Bottom-Up« , plus analytique exige beaucoup plus de travail détaillé au niveau de chaque livrable du projet pour en estimer efforts, durée et coûts. En général, elle est mise en œuvre grâce à la structure de décomposition du projet, le Work Breakdown Structure (WBS), et l’on s’efforce d’estimer les taches à réaliser au niveau le plus bas possible.

L’idéal est de faire appel à plusieurs méthodes d’estimation et d’en comparer les résultats.

Implication de l’équipe et du chef de projet

Pour que le projet soit un succès, il faudra que l’équipe projet s’approprie les dates, même imposées, ainsi que les estimations d’effort… Si nous prenons l’exemple de Scrum dans le logiciel, au début de chaque itération de développement sur le produit (le Sprint), les membres de l’équipe eux-mêmes ont souvent la possibilité de choisir dans la liste priorisée des besoins clients (le « product backlog ») les livrables qu’ils s’engagent à réaliser sur la période. Ils sont dès lors pleinement engagés sur la tâche et les délais.

Au minimum, le chef de projet doit pouvoir être intimement convaincu que les dates peuvent être tenues pour à son tour motiver son équipe sur les délais, le contenu et la qualité.

Plans réalistes et atteignables

Réalistes pour qui? En premier lieu pour l’équipe. Comme mentionné ci-dessus, le chef de projet et son équipe vont devoir répondre de manière positive aux questions suivantes: Parviendrons-nous à livrer un produit ou service dont nous serons fiers dans les délais? Quels sacrifices cela demandera-t-il et y sommes-nous prêts? Aurons-nous le support nécessaire de nos sponsors?

Vouloir maintenir une date malgré les retards au démarrage

Ce cas est hélas on ne peut plus fréquent. Les estimations fournies sont correctes et la date de fin septembre était atteignable en démarrant au 1er janvier. Mais voilà, nous sommes le 8 Mars et cela fait plus de trois mois que sponsors et financiers hésitent, posent des questions complémentaires, n’arrivent pas à trouver des créneaux horaires pour se rencontrer… Enfin, ils se sont vus ce matin et sont d’accord, nous avons le feu vert, bonne nouvelle! Et (moins bien) on nous demande de respecter la date de fin septembre et de ne pas dépasser les coûts!!! Cela peut vous paraître familier, j’en suis certain. Cependant, sauf à avoir gonflé outrageusement nos estimations (de 30%) ou pouvoir tailler dans le contenu des livrables, ce sera mission impossible, car accroître le volume de ressources de manière aussi drastique sur une aussi brève échéance semble peu plausible. L’une des pratiques à respecter pour éviter autant que faire se peut ce type de situation est d’inclure un jalon d’approbation du projet (JAP) dans le chemin critique du planning proposé et de n’exprimer les dates suivantes qu’en délais depuis cette date. Par exemple, l’analyse sera terminée 2 mois après le JAP, le design 4 mois, la construction 8 mois et la phase de test 9 mois (JAP + 9 Mois). Je sais, pas facile en pratique, mais cela vaut le coup d’essayer.

Implication du client

La date convient-elle réellement au client final? Par exemple, livrer un nouveau système de réservation hôtelière juste avant la saison touristique ne sera probablement pas une excellente idée. Peut-être vaudrait-il mieux attendre la saison creuse suivante et enrichir les fonctionnalités ou bien, au contraire, réduire celles-ci au strict minimum et livrer le système beaucoup plus tôt? De même, en comptabilité certaines périodes sont à éviter pour livrer des nouveautés: bilans, clôture de fin de mois, facturation, déclarations d’impôts… Il convient donc de bien s’assurer en amont de la pertinence des dates « imposées » par les sponsors et commanditaires et ne pas assumer qu’ils ont conscience de l’impact coté client.

Ressources

Pour une raison x ou y indépendante de votre volonté, il ne vous a pas été possible de recruter les ressources dans les temps: blocage des bons de commande aux achats, contrôles lent des recruteurs, réticences de certains managers à mettre à disposition les compétences requises… Pourtant les sponsors et commanditaires sont prêts à n’accepter aucun délai! En fait, ils ont probablement raison. C’est notre job de PM que d’anticiper, éviter ou surmonter ce type d’obstacles et de faire appel à eux pour faire sauter les blocages éventuels avant que le projet ne soit négativement impacté.

le PMBOK V4 est maintenant disponible en Français

Le par mopertodans best practices, forum de discussion8 commentaires

Le PMI est heureux d’annoncer la sortie de la version française du Guide PMBOK® – Quatrième édition.

Le Guide PMBOK® – Quatrième édition poursuit la tradition d’excellence dans le management de projet avec une norme plus facile à comprendre et à mettre en œuvre, avec une plus grande cohérence et clarté.


Quoi de neuf ?

• Un langage normalisé a été incorporé dans tout le document de manière à favoriser la compréhension par le lecteur.
• De nouveaux diagrammes de flux des données clarifient les données d’entrée et de sortie pour chaque processus.
• Une plus grande attention a été accordée au mode d’intégration des domaines de connaissance dans le cadre des groupes de processus de démarrage, de planification, d’exécution, de surveillance et de maîtrise, et de clôture.
• Deux nouveaux processus sont présentés : Identifier les parties prenantes et Recueillir les exigences.

Les membres du PMI ont l’avantage de pouvoir accéder sans frais à la version numérique du Guide PMBOK®—Quatrième édition.

The file is a watermarked PDF that includes your name and member ID. It is password protected with your PMI.org password and is licensed to you as a member benefit. La distribution, vente ou reproduction de ce fichier n’est pas autorisée.

Pour accéder à la version numérique :

1. Connectez-vous à PMI.org.
2. Click [enter URL]
3. Entrez votre mot de passe PMI.org.
4. Cliquez sur ‘Download’ [Télécharger].
5. Lorsque vous y êtes invité, sélectionnez ‘Save’ [Enregistrer] pour enregistrer le fichier PDF sur le bureau de votre ordinateur.

Pour ouvrir le fichier PDF :

1. Ouvrez le fichier PDF sur le bureau de votre ordinateur.
2. Lorsque vous y êtes invité, entrez votre mot de passe PMI.org puis cliquez sur ‘OK’.

Pour acheter votre exemplaire du Guide PMBOK®—Quatrième édition :

• Visitez le site commercial de PMI.org (prix pour les membres du PMI : US$49,50) ou
• Renseignez-vous auprès de votre bureau local du PMI ou
• Utilisez l’ISBN à 13 chiffres pour passer votre commande en ligne à niveau local ou dans votre librairie préférée.

Les bénéfices de la Documentation de Projet

Le par mopertodans best practices, forum de discussion1 commentaire

Voici un article qui m’a interpellé sur le blog de Gina Abudi. Il est écrit par  Dhanasekaran Sivaraj et sa version originale en anglais est lisible ici.

Documenter le projet ? ?

“Hummm…je préférerais passer ce temps sur d’autres activités plus importantes du projet.”

“Faisons-le après l’achèvement de toutes les activités du projet, pas tout de suite.”

“Je suis concentré sur la livraison du projet. La documentation peut attendre.”

“Je peux réaliser un projet de plus si je ne fais pas la documentation.”

Cela vous est familier ? Vous pouvez avoir entendu l’une ou toutes les excuses et les complaintes ci-dessus de beaucoup de chefs de projet, vous y compris. Ce sont des déclarations communément utilisées par les chefs de projet qui ne veulent pas faire un travail minutieux – ce qui signifie faire la documentation du projet. Si vous avez prononcé n’importe laquelle de ces phrases, il est temps de déposer une « Requête de Modification » pour changer votre perception de la documentation de projet.

La documentation de projet est un des secteurs les moins intéressants pour les chefs de projet car elle exige de nombreux efforts, mais est rarement applaudie par le chef. En réalité, cependant, la documentation de projet est un composant clef du management de projet et s’exécute du début à la fin de tout projet.

Examinons quelques points clefs à propos de la documentation de projet.

Pourquoi documenter ?

La documentation de projet est exigée pour réussir le projet. Elle est utilisée :

  • Pour définir le contenu du projet et s’assurer de l’accord de toutes les parties prenantes et des membres de l’équipe. Ainsi, toute personne impliqué dans le projet partage la même compréhension des attentes, de quoi faire, quand le faire, etc.
  • Pour établir une référence qui permettra de résoudre des différents et entre les parties prenantes si nécessaire.
  • Pour garder une référence historique qui fournit des informations détaillées sur le projet et peut être utilisée réussir de futurs projets.

Les bénéfices de faire la documentation de projet

En sus de ces raisons, la documentation de projet offre des avantages supplémentaires aux chefs de projet, y compris :

  • Une aide pour créer les Structures de Répartition de Travail (WBS) très détaillées qui aboutissent à l’élaboration de planning réalistes et réalisables.
  • Une diminution des surprises et risques inutiles.
  • Une aide pour prévoir l’avancement du projet pendant l’exécution et prendre des mesures proactives pour attaquer des défis.
  • Une compréhension claire des pré-requis de projet pour toutes les parties prenantes.

Et…le boss vous verra, le chef de projet, comme une personne soucieuse des détails et minutieuse dans son travail. Ce qui augmente votre valeur dans l’organisation et fait de vous un chef de projet désirable sur tous les projets majeurs.

Résultat final – changez votre perception sur la documentation de projet et commencez à vous concentrer davantage sur ce secteur. Vous commencerez à en voir les bénéfices en un rien de temps et vous augmenterez la probabilité de succès de vos projets avec moins de stress pour vous et pour l’équipe de projet.

Copyright © 2010 Dhanasekaran Sivaraj

Comment vous faire repérer par un chasseur de tête

Le par mopertodans best practicesLaisser un commentaire

Lisez l’article intégral original en Anglais

Bonne nouvelle, selon nos collègues Britanniques, après deux années volatiles, il y aurait des signes de reprise du marché de l’emploi– et les chasseurs de têtes chercheraient des talents pour répondre à la demande.

Pour l’instant, je n’ai pas personnellement ressenti ce redémarrage mais j’espère sincèrement que cette reprise est en train de traverser la Manche sans encombre pendant que j’écris cet article.

Quelques conseils en 4 étapes de BNET pour bien vous positionner dans cette chasse aux talents.

prérequis: attester de 18 mois dans votre job pour montrer votre sérieux, construire une expérience, augmenter la visibilité professionnelle et élargir votre réseau de contacts utiles.

1. Peaufinez votre Curriculum Vitae (CV)

But : S’assurer que son Curriculum Vitae est varié et assez détaillé pour répondre aux attentes.

Votre CV reste votre carte d’entrée, mais les chasseurs de têtes cherchant des managers peuvent le regarder d’un œil plus critique parce qu’ils rechercheront des qualités et compétences spécifiques.

Essayez d’éviter les clichés ou assurez-vous si vous dites que vous êtes ‘proches du terrain’ ou ‘stratégiques et orientés résultats’ que vous pouvez le confirmer par des preuves et des exemples spécifiques.

Une trajectoire de carrière inhabituelle peut jouer en votre faveur si elle démontre une expérience riche et variée – postes à l’étranger, projets à l’extérieur de votre secteur principal et même volontariat montreront que vous avez du répondant.

Un gros handicap serait une suite rapide de changement de jobs. Les chasseurs de têtes aiment voir que vous êtes capables de vous investir dans  un rôle.

2. Augmentez votre visibilité

But : Être reconnu comme un expert dans son industrie

Être reconnu de ses pairs serait la chose la plus importante sur laquelle se concentrer pour être remarqué par des chasseurs de têtes. Voici quelques idées :

– Identifiez les séminaires professionnels qui vous semblent pertinents et essayez d’y  intervenir en tant que speaker.

– (Re-)Découvrez votre réseau d’anciens étudiants et collègues.

– Gérez votre Identité Numérique : Quelles informations s’affichent quand vous tapez votre nom dans un moteur de recherche ? Votre présence en ligne sera examinée par les chasseurs de têtes, donc cela vaut la peine de vérifier que votre page de LinkedIn (et/ou Viadeo) est à jour et que votre profil de Facebook passe le filtre.

– Rejoignez votre corps professionnel, comme, pour les chefs de projets, PMI ou Prince2 ou IPMA (ou les 3, mais attention aux tarifs).

– Soyez cités : dans les magazines et les sites web de votre industrie ou profession. Recherchez celui que l’on considère comme étant ‘la Bible’ de votre industrie.

3. Courtisez les chasseurs de têtes

But : Entrer dans le radar d’un professionnel de recherche de senior management

Devenez l’un des contacts de plusieurs chasseurs de tête pour leur donner des informations sur vos pairs. La capacité à proposer des candidats potentiels sur un poste témoigne de la qualité de votre propre réseau – et vous les aidez à faire leur travail. Tôt ou tard, ils vous considéreront pour un poste parce que votre nom est toujours le premier qui leur vient à l’esprit.

Évitez les appels « à froid ». Essayez d’être introduit par un ami. Cela facilitera le premier contact.

Une fois que vous avez réussi à faire en sorte que votre chasseur de tête sache que vous existez, vous pouvez être invités pour une réunion en face à face, pour qu’ils puissent déterminer si vous méritez votre réputation.

4. Affûtez votre technique d’entretien

But : S’assurer que la première impression est durable

Vous n’aurez pas de deuxième occasion de faire une bonne première impression. Entraînez-vous à présenter vos compétences et votre expérience et peaufinez votre marque personnelle.

Qu’on le veuille ou pas, la robe importe aussi : Soignez votre apparence.

Écoutez soigneusement ce que l’on vous a demandé et allez au bout de votre pensée dans votre tête avant de répondre. Puis, répondez précisément – comme un cadre supérieur à son bureau exécutif.

Faites quelques recherches sur le chasseur de tête qui vous interviewe – vérifiez le site Web de sa société ou son profil sur les médias sociaux. Il est toujours flatteur qu’un candidat ait fait cet effort.

En conclusion

Excellent! Vous avez été remarqué; vous avez remis un CV impressionnant et avez passé avec succès l’entretien initial; ne vous congratulez pas trop vite. Le vrai boulot commencera quand vous serez présenté pour ce rôle important que vous recherchiez.

Remarques personnelles: J’ajouterais de ne pas oublier que ce job dont vous rêvez se trouve peut-être dans votre propre société. Donc, attachez-vous à appliquer les conseils ci-dessus aux potentiels recruteurs au sein de votre entreprise. Pour être bon face aux chasseurs de têtes, soyez bon dans votre job : la confiance en soi est un atout précieux que ces professionnels perçoivent dès les premiers instants.

contactez-nous pour publier une annonce
contactez-nous pour publier une annonce

10 minutes avec le grand chef pour parler de votre projet

Le par mopertodans best practices, experience sharingLaisser un commentaire

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.

L’article de Ty s’intitule: « When Presenting to Stakeholders—You’ve Only Got About a Minute ».

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…

B.A.-BA : répondre aux résistances

Le par mopertodans best practices, forum de discussion2 commentaires

Dans un article précédent, j’ai décrit le B.A.-BA: pour conduire des entretiens téléphoniques efficaces. Dans cet article, je voudrais me concentrer sur quelques éléments essentiels pour répondre aux résistances pendant des appels téléphoniques ou des réunions, particulièrement si vous devez vendre un projet ou une idée. De nouveau, rien de neuf sous le soleil pour les chefs de projet expérimentés ou les professionnels de la vente. Mais, ce qui va sans dire, va encore mieux en le disant.

J’ai appris qu’il y a essentiellement trois types différents de résistance qui doivent être reconnus et gérés : Perception incorrecte, Scepticisme et Problème. En réalité, la manière de répondre dans ces trois situations n’est pas si différente mais voyons cela au cas pas cas :

1. Perception incorrecte

Avoir une perception incorrecte c’est soit percevoir inexactement ou bien mal comprendre. Vous vous trouvez dans une situation où, après avoir exposé votre topo, vous avez écouté activement votre interlocuteur. Vous remarquez que votre message n’est pas compris. Il peut y avoir beaucoup de raisons à cela : la manière dont vous vous êtes exprimé; des idées préconçues ou un manque d’écoute de la part de votre interlocuteur; un sujet trop complexe pour être compris du premier coup; un domaine qui exige des connaissances préalables que l’autre personne peut ne pas posséder … Ce qui est nécessaire dans cette situation c’est tout d’abord d’établir qu’il y a une mauvaise perception, de fournir ensuite une clarification et de conclure par une nouvelle écoute et un questionnement pour confirmer l’accord.

  • Établir qu’il y une mauvaise perception : prouvez, en répétant autant que possible les mots utilisés par la personne, que vous avez identifié une perception incorrecte. Précisez que la faute est la vôtre. Cette mauvaise perception ou ce malentendu est survenu parce que vous n’avez pas encore été capable de transmettre votre message assez clairement pour convaincre la personne.

Par exemple : «je vous entends dire que vous comprenez que ce projet durera 2 ans et exigera 10 membres du personnel de l’entreprise. Je vois que je n’ai pas été clair dans mes explications et je voudrais clarifier ce point spécifique.»

  • Fournissez la clarification sur l’élément qui n’a pas été bien compris.

Dans notre exemple : «le projet durera en effet 2 ans et nécessitera 10 ressources avec la portée actuellement définie. Cependant, une option présentée est de composer l’équipe à  50/50 entre internes et externes. De plus, une deuxième option est  de réduire la portée initiale pour obtenir la  plus grande partie possible  des bénéfices sur une période plus courte, si vous pensez que c’est souhaitable pour l’entreprise.»

  • Et concluez avec une nouvelle écoute et des questions pour confirmer l’accord.

Dans notre exemple : «j’ai vu que vous avez hoché la tête quand j’ai clarifié que nous pourrions pourvoir le projet avec 50 % de ressources externes. Sommes-nous d’accord que cette option est une bonne approche pour construire le projet ?»

2. Scepticisme

Le scepticisme s’apparente très souvent à des doutes et un désir de suspendre son jugement par rapport à de nouvelles informations qui ne sont pas très bien supportées par l’argument ou l’évidence présenté. Quand vous remarquez que les informations que vous avez fournies ne sont pas bien acceptées et que ce n’est pas en raison d’un malentendu, mais plutôt du scepticisme, vous êtes dans une situation qui exige l’assurance ou la réassurance. Donc, reconnaissez le scepticisme, rassurez et concluez par une nouvelle écoute et des questions pour confirmer l’accord.

  • Reconnaissez le scepticisme : vous anticiperez souvent cette réaction potentielle en passant en revue votre proposition ou argumentaire. Vous vous mettez vraiment dans les chaussures de votre homologue pendant un moment et essayez de voir depuis sa perspective ce qui pourrait être douteux dans votre projet ou idée. Dans certains cas, vous pouvez tout simplement vous remémorez que, lorsque vous n’étiez pas encore familier avec le projet, vous aviez également eu des doutes . Utilisez ceux-ci pour montrer que vous comprenez le scepticisme de votre interlocuteur.

Par exemple : « je vois que vous semblez avoir des doutes sur les 2 ans de durée et 240 homme mois d’effort. Très sincèrement, c’était également ma première réaction quand j’ai reçu ces évaluations. »

  • Rassurez sur le sujet qui génère du scepticisme. Si vous le pouvez, fournissez davantage de faits et preuves sur votre argumentaire. Des benchmarks ou des études, des chiffres de projets antérieurs, des références (particulièrement de personnes que votre homologue connaît bien), des précédents, des statistiques, … sont autant de sources que vous pouvez utiliser pour rassurer la personne sur le sujet.

Dans notre exemple : «Aussi, j’ai questionné l’équipe pour comprendre les détails. Et, ils ont été capables de me montrer les chiffres d’un projet précédent de complexité et portée semblables. Il avait coûté 360mm avec 12 ressources sur 2 ans et demi. Grâce à cette expérience, ils ont été capables de réduire la durée de notre projet à 2 ans et la taille d’équipe à 10 ressources au lieu de 12. Une amélioration de 30 % et avec une équipe qui a déjà réalisé un projet semblable.»

  • Et concluez avec une nouvelle session d’écoute et de questionnement pour accord.

Dans notre exemple : «vous avez semblé être sur la même longueur d’ondes que moi quand j’ai exposé la façon dont les évaluations ont été construites. Êtes-vous plus à l’aise avec cet aspect du projet ?»

3. Problème

«J’ai un problème …» est la méthode traditionnelle de remonter une préoccupation, un souci, lors d’une réunion. C’est une déclaration très puissante et qui, si elle n’est pas réglée, peut tout stopper. Si votre contrepartie ne l’exprime pas ouvertement, mais vous pouvez voir qu’il y a un problème réel pour lui ou elle, posez la question: «À votre avis, quel pourrait-être le problème-clé ou la préoccupation que le projet  devrait adresser  en priorité ?». De nouveau, ce qui est exigé dans cette situation est en premier lieu de reconnaître qu’il y a un problème, ensuite réaffirmer les points forts de votre proposition, chercher une résolution et conclure par une nouvelle écoute et des questions pour confirmer l’accord.

  • Reconnaissez le problème : assurez-vous que vous comprenez précisément le souci. Est-ce le coût, les délais, le contenu, l’approche, la dotation en personnel, les compétences, les conditions de paiement ? Prouvez, en réutilisant autant que possible les mots de la personne, que vous avez vraiment compris où se situe le problème.

Par exemple : «je vous entends mentionner comme un problème le fait que le projet durera 2 ans et exigera 10 membres du personnel interne. Et que la durée est une réelle préoccupation ou un point de blocage pour vous parce que votre fenêtre d’opportunité pour lancer ces nouveaux services sur le marché n’est que de 18 mois.»

  • Réaffirmez les points forts de votre proposition et utilisez des accords établis précédemment pour renforcer les bénéfices escomptés. Réitérez l’équation besoins/bénéfices du projet.

Dans notre exemple : «Nous avons établi ensemble que ce nouveau projet est absolument nécessaire pour permettre à la société de livrer ces nouveaux services. Des études préalables ont établi que des modifications  aux systèmes existants coûteraient davantage et demanderaient plus de temps. De plus, nous sommes d’accord sur la portée du projet en termes de contenu et d’évaluation des charges. Ce projet permettra aux nouveaux services d’être développés et exploités efficacement.»

  • Cherchez la résolution avec votre contrepartie pour éliminer ou contourner le problème.

Dans notre exemple : Ce projet durera en effet 2 ans avec 10 ressources pour la portée actuellement définie. Cependant, une option que nous avons examinée est de réduire la durée en amenant des ressources supplémentaires pour exécuter certaines tâches en parallèle plutôt que séquentiellement. D’autre part, nous avons également l’option mentionnée précédemment de réduire la portée initiale pour nous concentrer sur les fonctions les plus critiques. Celles qui permettront de répondre à la majorité des besoins sous 18 mois, avec quelques adaptations de processus. Puis, nous livrerons une version qui couvrira la totalité du périmètre un peu plus tard.»

  • Et concluez avec une nouvelle écoute et questionnement pour accord.

Dans notre exemple : «j’ai vu que vous avez été sensible à l’option d’ajouter du personnel externe sur le projet. Sommes-nous d’accord que ce serait une bonne approche pour avancer sur le projet ?»

Bien sûr, les chefs de projet ne sont pas des commerciaux professionnels, mais connaître quelque-unes des ficelles pour mieux répondre aux résistances pendant des réunions est une compétence fort utile dans nos vies professionnelle et privée.

B.A.-BA – conduire des entretiens téléphoniques efficaces

Le par mopertodans best practices, forum de discussion1 commentaire

Je suis souvent étonné du manque apparent de professionnalisme dont font preuve certaines personnes dans leur manière de conduire des entretiens téléphoniques. En particulier lorsqu’ils ont lieu avec des clients, prospects, commanditaires, ou des niveaux de direction.

Je me demande si certaines des bases que nous avons appris très tôt dans notre vie professionnelle n’ont pas été oubliées. Dans mon cas, cet apprentissage s’est déroulé alors que les téléphones portables étaient « portatifs »,  la messagerie instantanée à inventer, sans parler des gazouillis de Twitter… C’était également une époque où les coûts de télécommunication étaient beaucoup plus élevés que de nos jours. Ceci explique peu-être pourquoi certaines de ces bases pourraient vous paraître dépassées. Pourtant, je les trouve encore extrêmement d’actualité dans mes communications téléphoniques.  Je considère qu’elles démontrent un respect envers mon interlocuteur et le temps qu’il ou elle me consacre.

Vu le temps que les chefs de projet passent sur ce type de communication, J’ai pensé qu’il pourrait être utile de partager la structure que j’essaie toujours de suivre.  C’est en fait très simple:

1. saluer la personne, se présenter et créer une atmosphère: si c’est une personne avec laquelle je parle souvent et connais assez bien, il est facile de rompre la glace avec quelques mots sur un sujet d’intérêt commun. Sinon, je reprends mes notes d’interactions passées ou je fais une rapide recherche Google , LinkedIn ou Viadeo pour trouver une accroche. Et, si la personne est référencée sur votre annuaire d’entreprise intranet, lisez sa fiche et regardez sa photo pour mettre un visage sur le nom.

2. positionner: confirmer le pourquoi de l’entretien et ses objectifs.

3. confirmer la durée: valider l’heure à laquelle l’entretien devra prendre fin et ne pas en déroger sauf sur demande de la personne appelée.

4. communiquer le plan de l’entretien: lister les sujets que vous aimeriez couvrir pendant cette session. Cela permet de se repérer pendant l’appel, cela évite les surprises, et aide à structurer l’appel et à gérer le temps.

5. écouter, valider l’accord: confirmer avec la personne que le plan proposé lui convient et demander si d’autres sujets devraient être ajoutés (ou certains enlevés).

6. dérouler l’appel en suivant le plan proposé et en s’assurant sur chaque point d’une compréhension commune par des questions de vérification et de validation.

7. faire un résumé de l’appel: Cette étape me permet de vérifier mes notes; de m’assurer que tous les sujets ont été couverts et si cela n’est pas le cas prévoir un appel ultérieur; et, d’expliciter ma compréhension de ce qui a été dit.

8. écouter, valider l’accord: Prendre le temps de vérifier que ma compréhension est correcte et que je n’ai rien oublié.

9. prendre note des actions: Il est temps de vérifier que nous avons bien un jeu commun d’actions agréées.

10. écouter, valider l’approbation: Pour confirmer nos engagements respectifs sur ces actions.

11. remercier la personne de son temps et contributions et pour les actions qu’elle a accepté de mener.

Ensuite, je m’efforce de ne jamais oublier de faire un suivi des actions sur lesquelles nous sommes d’accord.

back to basics for running effective calls

Le par mopertodans best practices, forum de discussion3 commentaires

I’m often amazed by the apparent lack of professionalism some people demonstrate in running calls, especially with sponsors, customers, prospects, senior management…

I wonder if some of the basics we learned early in our careers have not been forgotten. In my case, I learned these when cell phones, instant messaging, tweets… did not yet exist, and also  at a time when telecoms costs were much more significant than Today. This may explain why some of these basics may seem a bit outdated. However, I personally still find them very very relevant in my day to day communications. I think that they also are a display of my respect towards the person I’m calling and for the time he or she dedicates to discuss with me.

Given time that Project Managers spend on calls, I thought that it could be useful to share how I always try to structure to be in good position. It is quite simple:

1. greet, introduce and relate: if I speak frequently with the person, it is quite simple to find « small talk » topics to break the ice. If I do not know the person very well, I’ll try to refer back to my notes from prior interactions, or perform a quick Google or LinkedIn search. And, if the person is referenced on the intranet directory, look at her information and picture to put a face on the name.

2. position: confirm the purpose and objectives of the call

3. confirm timing: confirm until when you have for this call and then do not overrun unless requested by the person you call

4. communicate plan: provide a rapid outline of the topics you’d like to cover during the call. It avoids surprises, it helps to structure the call and also it gives a way to check progress versus time allotted for the call.

5. listen/probe for agreement: confirm with the person that this plan is OK and ask if topics should be added or removed in their opinion.

6. run the call following the above plan and constantly probing, listening and confirming my/our mutual understanding

7. summarize the call: This step allows me to check my notes, verify that all topics we wanted to cover have been. And, if it’s not the case agree to a follow up call. Repeat my understanding of what has been said.

8. listen/probe for agreement: Take the time to check that my understanding is correct and verify that I haven’t missed any point.

9. propose actions: Now it’s time to double check that we have a common set of agreed actions.

10. listen/probe for commitment: This is to confirm our respective commitments to conduct the above actions

11. thank the person for their time and contributions and for accepting some of the above actions.

Then, I try to never forget to follow through on the actions we agreed.

why quick fixes often lead to more trouble

Le par mopertodans best practices, forum de discussion1 commentaire

As project managers, we’re often compelled to get roadblocks out of the way as fast as possible so the team can continue to progress. 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.

The way it usually starts:

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.

2.We apply a quick fix. 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.

However, are we sure to have

a) addressed the root cause of the problem and

b) assessed the potential side effects of the quick fix we applied?

Let’s see what too often takes place after the initial quick fix.

3. The quick fix addresses the symptom but it has some side effects. 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…

4. These side effects will manifest through new symptoms: Bad morale in the team, threats of delays in other parts of the project, absenteeism…

5. We’re tempted to address these new symptoms with more quick fixes.

The loop goes on. The initial quick fix may have placed the entire project at risk.

So, what to do? How do we break the vicious spiral?

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:

  • Were the estimates incorrect?
  • Did a risk materialize that we had or not accounted for?
  • Were there changes to the requirements and how were these managed?
  • Were some resources not available when they should have been?
  • Was the learning curve incorrectly appreciated?
  • Did we encounter technical issues?

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. »

Pourquoi les réparations rapides amènent-elles souvent plus de problèmes qu’elles n’en résolvent ?

Le par mopertodans best practices, outils et méthodesLaisser un commentaire

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. 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 (« quick fix »). 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.

Voici comment cela commence habituellement :

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.

2. Nous appliquons alors une réparation rapide. 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.

Cependant, sommes-nous sûr d’avoir

a) Attaqué la cause première/racine du problème et

b) Évalué les effets secondaires potentiels de la réparation rapide ?

Voyons ce qui arrive trop souvent après une réparation rapide.

3. La réparation rapide adresse le symptôme mais elle a quelques effets secondaires. 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 …

4. Ces effets secondaires se manifesteront par de nouveaux symptômes : mauvais moral dans l’équipe, menaces de retards sur d’autres parties du projet, absentéisme …

5. Nous serons tentés d’adresser ces nouveaux symptômes par davantage de réparations rapides.

La boucle continue. Cette réparation rapide initiale peut avoir placé tout le projet à risque.

Aussi, que faire ? Comment casser ce cercle vicieux ?

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:

  • Est-ce que les évaluations de charge étaient incorrectes ?
  • Un risque s’est-il matérialisé que nous n’avions pas prévu ou incorrectement managé ?
  • Un changement des besoins est-il intervenu et comment a-t-il été géré ?
  • Est-ce que des ressources n’étaient pas disponibles quand elles auraient dues l’être ?
  • La courbe d’apprentissage a-t-elle été mal appréciée ?
  • Avons-nous rencontré des difficultés techniques ?

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. »

le management par l’écoute et la rencontre pour les chefs de projet (MBWA)

Le par mopertodans best practices, outils et méthodes5 commentaires

Voici un rappel intéressant d’une méthode qui n’a rien de nouveau et n’a pourtant pas perdu en efficacité dans le monde du web 2.0 où règnent les relations virtuelles.

Original article in English by Kareem Shaker, Dubaï, Émirats Arabes Unis.

Traduction personnelle et approximative:

Vous ne pouvez pas gérer les gens depuis une tour d’ivoire, vous devez interagir avec votre équipe, parler avec eux tous les jours et faire tomber une barrière qui peut être un élément important de démotivation dans beaucoup d’organisations. Le management par l’écoute et la rencontre (Management By Wandering Around/MBWA en Anglais) est une technique simple mais efficace pour créer et maintenir un lien solide avec votre équipe qui soit bâtit sur la confiance mutuelle, la compréhension et l’accord.

MBWA est une des techniques les plus efficaces à pratiquer sur le lieu de travail et  beaucoup de managers l’utilisent pour envoyer un message silencieux “je suis ici!” aux membres du personnel. Je suis certain que vous l’avez déjà expérimenté lors de votre carrière professionnelle. Alors que vous étiez assis et totalement absorbé par votre écran, soudainement, vous avez trouvé le grand chef (l’HIPPOPOTAME) de votre organisation debout à deux ou trois mètres de vous et il vous a demandé “qu’essayez-vous de résoudre ?!”

Cela s’appelle le management par l’écoute et la rencontre, cela semble très simple et n’exige aucune compétence spécifique. Pourtant, c’est très efficace et c’est l’une des meilleures techniques de motivation que vous puissiez utiliser. En tant que chef de projet qui doit rester en contact avec les gens, vous devez comprendre leurs problèmes et les aider à les résoudre. Dans cet article, je donnerai à quelques façons de commencer à pratiquer le MBWA. L’essayer c’est l’adopter, et vous percevrez certainement la différence. Cet article s’adresse particulièrement aux chefs de projet mais il peut aussi aider les managers de tous les niveaux à la pratique du MBWA.

Réunions Quotidiennes Debout

C’est un des thèmes principaux de Scrum, cependant, en pratiquant le MBWA, la réunion debout (« standing meeting ») n’a pas besoin d’être quotidienne. Ce peut être simplement une réunion rapide pour faire le point avec l’équipe des problèmes, progrès, statut, et ainsi de suite. La beauté des réunions debout est ce que cela peut sembler spontané et non prévu. Vous pouvez dire à l’équipe: “faisons la réunion d’aujourd’hui debout, nous serons ensemble pendant 10 à 15 minutes et parlerons du projet”. Il n’est pas nécessaire d’utiliser Scrum pour avoir une réunion debout. En fait, elle peut éliminer la lassitude vis-à-vis des réunions habituelles où trop de temps est gaspillé. Vous n’êtes pas forcé au formalisme pendant la réunion, utilisez des mots qui motivent et remerciez l’équipe de chacun de leurs petits accomplissements (pour exécuter des réunions efficacement, lisent mon article: Better Meetings.)

Les prendre sur le vif alors qu’ils font quelque chose de bien

Un des aspect de la technique dite « The One Minute Manager » développée par Kenneth H. Blanchard est de surprendre les salariés pendant qu’ils font quelque chose de bien pour le projet, même petit, et de les remercier de le faire. Cela motivera tous les membres de l’équipe et augmentera leur niveau de productivité. Si vous passez devant un membre de l’équipe qui fait quelque chose de bien, remerciez-le et exprimez votre satisfaction de le voir faire les bonnes choses, cela stimulera toujours les membres de l’équipe à bien travailler et à améliorer les livrables du projet. Donc, ceci améliorera l’organisation toute entière.

Présentez les membres inconnus de l’équipe aux Clients

Il arrive souvent que vos clients ne soient pas conscients de toute l’équipe projet. Ils peuvent interagir avec le leader d’équipe, et à peine connaître les développeurs. Vous pouvez utiliser la première réunion dans les locaux de l’équipe pour une visite des clients sur le lieu de travail et leur présenter les membres de l’équipe en expliquant leurs rôles et responsabilités. Ceci est un réel motivateur.

Posez des Questions Rafraîchissantes

Les questions ne devraient pas être liées au projet. Vous devrez socialiser avec l’équipe et mieux connaître leurs centres d’intérêt, passe-temps, familles, soucis, et ainsi de suite, vous pouvez utiliser n’importe laquelle des questions suivantes (remplacer les  mots en italiques):

  • Comment était votre week-end ?
  • Comment est votre déplacement pour venir au bureau? Combien de temps dure-t-il?
  • Avez-vous vu le film d’Avatar ou Milan AC contre Inter Milan ou le show d’Oprah ?
  • Avez-vous lu le dernier livre de Dan Brown ?
  • Avez-vous essayé la version bêta de Microsoft Office 2010 ? (Donnez-leur indirectement des astuces pour stimuler leur connaissance)

Claironnez les Bonnes Nouvelles

Rien ne motive l’équipe comme les bonnes nouvelles. Essayer d’utiliser les bonnes nouvelles même petites pour faire plaisir à l’équipe. Allez dans leurs bureaux et dites haut et fort “Mesdames, Messieurs, j’ai quelques bonnes nouvelles, NOUS …”. N’oubliez pas d’utiliser « NOUS » et abstenez-vous d’utiliser « JE ».

Récapitulatif

MBWA est une technique puissante à utiliser par l’encadrement, les directeurs, managers et chefs de projet. C’est l’une des caractéristiques d’un manager qui réussit. Ce doit être nourrit et appliqué savamment, et aussi pratiqué spontanément. Cependant, si vous vous n’avez pas envie de l’utiliser, ne vous forcez pas, car s’il est utilisé à tort il démotivera les membres de l’équipe et aura un effet contre-productif. Vous devrez le faire de manière rapide et ne pas y dépenser trop de temps à marcher autour d’eux et ne pas leur laisser penser que vous vérifiez ce qu’ils font!

Partagez votre Expérience

Si vous utilisez le MBWA et avez d’autres techniques qui marchent bien pour vous, ou si vous avez utilisé quelques techniques qui n’ont pas fonctionné avec vous, partagez s’il vous plaît votre expérience et laissez un commentaire!

davantage de bonnes résolutions sur lesquelles construire 2010

Le par mopertodans best practices, forum de discussionLaisser un commentaire

Merci aux nombreux lecteurs de ma note précédente sur 10 bonnes résolutions pour 2010 et particulièrement à ceux qui ont pris le temps de m’envoyer des remarques et proposer ces suggestions supplémentaires.

11.  Fournir du tutoriat et du coaching aux futurs chefs de projet. Dans la ligne des résolutions 1. Développez des membres de l’équipe et 10. Concentrez-vous sur le peuple(les gens); il est vrai qu’un ensemble spécifique de personnes que nous devons aider est celui des chefs de projet futurs ou juniors. Cela peut être aussi simple que leur demander régulièrement comment les choses avancent sur leur projet, quels aspects leur parait difficile, ce qui consomme leur temps, quels sont leurs risques critiques … Et ensuite leur soumettre quelques idées utiles, des pointeurs, des matériels ou modèles appropriés pour adresser leurs soucis, ou leur offrir un peu de temps pour discuter et peser les idées qu’ils pourraient avoir. Je dis spécifiquement « quelques » car les accabler de conseils, pointeurs, ou questions, serait contre-productif selon mon expérience.

12.  Gérez vos parties prenantes. Une autre bonne résolution très intéressante et pas facile étant donné la variété de parties prenantes. Un bon point de départ peut être de décider de systématiquement passer un peu de temps au début de chaque phase du projet à identifier les personnes qui ne sont pas dans la chaine décisionnelle, ni dans le management des fonctions directement incluses par le projet (car nous connaissons déjà probablement très bien celles-ci). Ainsi, essayer d’identifier d’autres personnes que le projet impactera et quel impact exactement il pourrait avoir sur eux. Puis, passez en revue leur pouvoir et influence relatifs et comment elles pourraient réagir et prévoyez comment accroître leur support au projet et prévenir des attitudes négatives.

13.  Gérez le contenu du projet à n’importe quel coût. Pas de placage à l’or fin pour qui que ce soit. Davantage d’infos sur ces sujet dans les articles Le contenu commande les coûts et planning du Projet et Comment écrire l’Enoncé des Travaux.

14.  Prévoyez, identifiez et gérez des risques. Assurez-vous que les parties prenantes clefs sont conscientes des risques à tout moment. Oui, je sais, cela semble assez évident, mais c’est également le cas de bien d’autres suggestions mentionnées.

15.  Assurez les leçons apprises sont capturées et communiquées. C’est celle que je trouve la plus difficile à garder sur cette liste. En tant de nouveau PMP, j’avais commencé avec enthousiasme, essayant de faire des sessions sur les leçons apprises à la fin de chaque phase du projet et non seulement à la clôture. Avec préparation de documents pour communiquer sur les découvertes intéressantes, organisation de sessions de revue et de partage … Cependant, il s’avère que la plupart des personnes n’étaient pas très intéressées à écouter les leçons de mes projets. Leur perception est souvent que leur projet est unique, donc différent et que cela demande trop d’efforts pour eux d’essayer de comprendre comment appliquer mes leçons à leur environnement. Néanmoins, si vous avez le temps, ils sont tout à fait enclins à partager leurs propres leçons apprises sur leur projet avec vous … Néanmoins, ce blog témoigne du fait que je continue à partager autant que possible avec les autres, peut-être d’une façon légèrement différente.

16.  Définissez les rôles et responsabilités de chaque membre de l’équipe.

17.  Communiquez efficacement avec tous les membres de l’équipe de projet, les parties prenantes, les sponsors etc. Ayez d’un plan de communications efficace, éxécutez-le et maintenez un fort niveau de communication pour amener les gens à votre cause et maintenir leur implication. Il y aura toujours une ou deux personnes difficiles: c’est la vie.

18.  Alignez toutes les ressources sur un but commun, particulièrement quand vous travaillez avec des ressources de multiples départements, assurez-vous que chacun reste concentré / engagé sur les mêmes objectifs. Il est très facile de perdre des ressources allouées par des départements différents du votre quand les priorités fonctionnelles évoluent avec le temps qui passe et les ressources sont alors changées ou redistribuées.

19.  Ne prenez pas de bonne résolution du tout (à moins que vous ne soyez vraiment engagé à les suivre à la trace et à les réaliser avec succès).

Enfin, plusieurs chefs de projet professionnels m’ont indiqué que toutes ces résolutions sont simplement les choses habituelles à faire pour être un Chef de projet acceptable. Un simple retour à essentiel ?

10 good resolutions for a Project Manager in 2010

Le par mopertodans best practices, experience sharing, forum de discussion2 commentaires

As we enter a new year and even a new decade, it could be an appropriate time to look at good resolutions I could take (and that you may want to consider) to improve my (your) effectiveness in Project Management.

  1. develop project team members
  2. understand the business objectives of the project
  3. respect all commitments that I accepted
  4. plan the full project in details and execute in steps
  5. know, communicate and manage the critical path
  6. anticipate and plan for changes
  7. demonstrate flexibility
  8. do not fudge with PM ethics
  9. lead with a positive and collaborative attitude
  10. focus on people

1.     develop project team members

Very early in my professional life, as I was reaching my first management position, I met with Yves, a great Human Resources Director at Digital Equipment. He asked me: « what is the number 1 priority for a manager? ». As I was still reflecting on the question, his own answer came very clear and loud: « your priority #1 is to develop the resources that are under your responsibility. If there is only one thing you shall learn from working at DEC, this is it! » While Yves was referring to people management roles rather than project management at the time, I strongly feel that his advice applies even more so to PMs.

As a project manager, resources are under my leadership for the duration of the project, it is my responsibility to get the best out of these project team members and also help them grow as much as possible.

Doing so serves the project; it will help the team members to find an interesting next assignment when the project completes; and it benefits the company that gains better resources working for it. It can be done through a combination of exposure to new tasks, coaching, challenging members to go further, providing them the support and training they need. Of course, a prerequisite is to know my team members. I’ll need to have a good understanding of their strengths and weaknesses, their past experiences, and their personal objectives, to build on these for the success of the project and their own professional development.

2.     understand the business objectives of the project

Too often, as a project manager, I was told about my project objectives only in terms of schedule, deliverables and budget, without real explanations about why the project was critical or important for the business. So, I focused on delivering a quality product on time and on budget. Not so bad.

But, on one occasion (the deployment of an Enterprise Resource Planning solution) it came as a surprise to me that, while the sacred triangle of Project Management had been fully satisfied and somewhat exceeded on one of the dimensions (23M of costs versus 25M budgeted), my customers were only partially satisfied. How could this be? Well, I learned that the project as defined did not fully take into account what critical users would perceive as success. Their perception was in fact limited to the reports they could get from the system to run the business. They had little if any visibility of how the reengineered processes drove greater efficiency, or the guaranteed data integrity of the new systems, or the improved data consolidation mechanisms, or the benefits coming fro the unification of processes…

So, on my projects in 2010, I will ensure that I better understand the business results expected by my customers, how they will perceive and measure these and how I can establish a baseline, with a picture of the current situation, to put in evidence the improvements brought by the project.

Understanding the expectations that key stakeholders have of the project will also make it easier for me to communicate clearly to the project team and to focus our attention on these.

3.     respect all commitments that I accepted

The first thing I shall do to enable the above is to learn to say « NO ». It is never easy to say no but we all learn the hard way that it’s even more difficult to respect an unachievable commitment.

This applies of course to project budget, schedule, resources… It also applies to how I handle relationships with others: team members to whom I could be tempted to make promises that are beyond my control (especially true in the matrix organizations we often evolve into), sponsors who can decide to appoint another PM, stakeholders who often have conflicting but nevertheless understandable requirements, boss who has pressure from the top…

It will also be wise that I order these commitments by priority for my customers and that we are very clear on which ones leave room for negotiation if need be.

One of my first managers used to say: « time, cost, quality: pick any two and give me some freedom on the third one ».

4.     plan the full project in details and execute in steps

I will plan the full project in as much details as possible. Of course, the immediate next phases may be planned with greater granularity but it’s important to have a reasonable level of details for the entire project. Without this, it is not possible to predict the time and costs and resources required over time for the project. This also sets the tone and makes the overall project’s deliverables clear for me and for team members as well as stakeholders and sponsors.

It is also particularly useful to have the full view before accepting to crash or timebox the project’s schedule or to respond to a demand to do it with limited resources or budget. It allows me to understand where I and the team are making compromises, the risks this creates and to reset expectations accordingly.

The execution of the project will in my experience almost always benefit from staged or phased deliverables. It allows the team to focus on a limited scope; it energizes us to meet a deadline that’s closer to us; it creates confidence in ourselves and builds trust with the customer as he can start to see and touch some deliverables; a quicker feedback loop is there in case adjustments are required; and it enables progressive testing.

5.     know, communicate and manage the critical path

The critical path is a good communication tool towards teams and management. It presents a logical succession of tasks that lead to a successful conclusion when all are executed on time. It enables focus on key tasks and can serve as a basis for prioritization decisions.

However, most PM tools will display only one critical path on my project based on resources, dependencies between tasks and progress made. I have learned over time that there may be multiple other critical activities that the tool will not detect as « critical path » tasks. However, some could lead to greater delays if not completed on time. An example on one of my projects was the task related to communicating an IT application’s objectives to the end users whose work would be impacted upon its introduction. We had plenty of time to do this while building the software and it took only a few days to execute it in the end. Because it was not highly visible on the project’s critical path (small effort, due date quite late in the schedule), we focused on it very late and it caused major issues for the project when treated as a rush activity.

So, apply your experience, common sense and your holistic understanding of the project rather than blindly trust the critical path proposed by the tool you use. Question the proposed critical path to understand why some tasks you did not suspect to be critical are there and others that your guts tell you to worry about are not on the critical path,.

6.     anticipate and plan for changes

First things first, in order to anticipate changes, I will start by solidifying the requirements with a very strong stakeholders’ buy in to establish a clear scope and perimeter for the project.

Of course, this will never prevent justifiable changes to be required but it can limit them significantly. And, I will implement a clear, simple and fast turn around process to handle demands for modifications, including who may submit them, the vetting process, the estimating approach and decision criteria.

I will also keep in mind that the process does not operate in a vacuum and that changes outside the project’s perimeter will potentially affect it. It could be a change of an executive who happens to be a stakeholder, a move of the competition, new entrants or modifications in the market place…

By the way, there could be positive changes that enable me to produce better deliverables sooner or cheaper. For example, it happened to me that a service management system we were developing for one of our regions was then selected to be rolled out Worldwide. While it increased the project’s scope, costs and timeline, the cost per end user of the solution was drastically reduced overall, enabling greater and more homogenized services for the company at lower cost.

7.     demonstrate flexibility

Of course, I learned as a project manager a number of approaches, methods and best practices for each of the nine specific knowledge areas of project management proposed by PMI® (www.pmi.org): integration, scope, risk, time, cost, quality, human resources, communications and procurement.

However, it is of crucial importance that I remain open and flexible about which one to apply to my specific project and context. For example, an agile development approach may fit well the software development of a new web front end for monthly Key Performance Indicators visualization, while a waterfall approach may be better suited for an Enterprise Resource Planning solution deployment.

I will also always look for new techniques, approaches, and tools. Especially ones other team members may have experienced with success on prior projects. I.e. I’ll always be looking for ways to learn and progress. For example, I learned to implement very productive short daily issues review meetings for critical projects as it had been successfully used in the past by our sponsor. On a different project, I learned about the criticality of learning about local culture. I tried (unsuccessfullyL) to run a brainstorming session with my Japanese colleagues before understanding that there was a better suited approach to draw requirements and establish priorities with them.

8.     lead by example with the PM ethics

Since 1981, PMI® developed progressively a code of ethics and professional conduct. http://www.pmi.org/PDF/ap_pmicodeofethics.pdf

As certified Project Management Professional (PMP®), I am committed to doing what is right and honorable. This Code of Ethics and Professional Conduct describes the expectations that we have of ourselves and our fellow practitioners in the global project management community. It articulates the ideals to which we aspire as well as the behaviors that are mandatory in our professional and volunteer roles.

I will continue to make mine these values that the global project management community defined as most important: responsibility, respect, fairness, and honesty.

9.     lead with a positive and collaborative attitude

I will certainly continue to be under heavy pressure from management and customers to deliver a superb product in a reduced timeframe and with limited resources.

This shall not prevent me from creating and maintaining a positive attitude in the team.

I shall also provide a collaborative environment where the team’s communications are facilitated. The tools are there, we just need to facilitate their implementation and usage.

The objective is to build an atmosphere that recognizes the urgency, the pressure, the amount of effort required by each of us and also one that shows confidence in our joint ability to succeed. The project manager like any leader is looked at by collaborators a little bit as an orchestra conductor. So, his positive leadership sets the tome and influences the overall ability of each player as well as the perception of the customers and engagement of stakeholders. More on Project Leadership.

10. focus on people

Focus on people: the team members I shall develop (see resolution 1), the customers and stakeholders I shall satisfy (see 2, 3, 6), my family with whom I will spend as much quality time as possible.

I will keep in mind that a project is a temporary endeavor while the relationships I build during its course last much longer.

10 bonnes résolutions pour un Chef de projet en 2010

Le par mopertodans best practices, experience sharing, forum de discussion2 commentaires

Comme nous entrons dans une nouvelle année et même une nouvelle décennie, ce pourrait être un moment approprié pour examiner les bonnes résolutions que je pourrais prendre (et que vous pourriez vouloir envisager) afin d’améliorer mon (votre) efficacité en Management de projet.

  1. Développer les membres de l’équipe projet
  2. Comprendre les objectifs business du projet
  3. Respecter tous les engagements que j’ai acceptés
  4. Planifier le projet en entier dans le détail et l’exécuter par étapes
  5. Connaître, communiquer et gérer le chemin critique
  6. Anticiper et gérer les changements
  7. Faire preuve de flexibilité
  8. Ne pas badiner avec l’éthique de Chef de Projet
  9. Manager avec une attitude positive et collaborative
  10. Se concentrer sur les personnes

1. Développer les membres de l’équipe projet

Très tôt dans ma vie professionnelle, comme j’atteignais ma première position de manager, j’ai rencontré Yves, un excellent Directeur des Ressources Humaines chez Digital Equipment. Il m’a demandé : « quelle est la priorité numéro 1 pour un manager ? ». Comme je réfléchissais encore à la question, sa propre réponse est arrivée très claire et forte : « votre priorité #1 est de développer les ressources qui sont sous votre responsabilité. S’il y a seulement une chose vous apprendrez chez DEC, c’est cela! » Bien qu’Yves se référait à ce moment là aux rôles de management de personnels plutôt que de projets, je suis convaincu que son conseil s’applique tout autant aux chefs de projets.

En tant que chef de projet, des ressources sont sous mon leadership pour la durée du projet, c’est ma responsabilité d’obtenir le meilleur de ces membres de l’équipe projet et les aider également à se développer autant que possible.

Cette approche sert le projet; elle aidera les membres de l’équipe à trouver une prochaine mission intéressante quand le projet sera terminé; et elle bénéficie à la société qui y gagne de meilleures ressources à son service. Ce développement des équipiers peut être réalisé par une combinaison d’exposition à de nouvelles tâches, de conseil, de les pousser à aller plus loin, de leur fournir l’appui et la formation nécessaire. Bien sûr, un préalable est de connaître mes membres de l’équipe. Je devrai donc avoir une bonne vue de leurs forces et faiblesses, de leurs expériences passées et objectifs personnels, me baser sur ceux-ci pour le succès du projet et pour leur propre développement professionnel.

2. Comprendre les objectifs business du projet

Trop souvent, comme chef de projet, j’ai reçu mes objectifs de projet seulement en termes de délais, de livrables à fournir et de budget, sans explications réelles de pourquoi le projet était critique ou important pour l’entreprise. Aussi, je me suis concentré sur la livraison d’un produit de qualité à l’heure et dans le budget. Pas si mal…

Mais, sur un projet (le déploiement d’un Progiciel de Gestion d’Entreprise – ERP), j’ai eu la surprise, alors que le triangle sacré du management de projet avait été satisfait et même quelque peu excédé sur l’une des dimensions (23M de dépenses sur les 25M budgétisés), mes clients n’ont été que partiellement satisfaits. Pourquoi ? J’ai appris alors que le projet tel que défini ne prenait pas totalement en compte ce que les utilisateurs critiques percevraient comme un succès. Leur perception était en fait limitée aux rapports et états qu’ils pourraient tirer du système pour manager le business. Ils avaient peu de visibilité sur l’efficacité plus grande des nouveaux processus métier, ou sur la garantie d’intégrité des données des nouveaux systèmes, ou sur les améliorations des mécanismes de consolidation de données, ou les avantages provenant de l’unification des processus…

Aussi, sur mes projets en 2010, je m’assurerai que je comprends mieux les résultats business attendus par mes clients, comment ils percevront et mesureront ceux-ci et comment je peux établir une base de départ, avec une image exacte de la situation actuelle, pour faire la preuve (l’évidence) des améliorations apportées par le projet.

La compréhension des attentes (exprimées ou pas) des parties prenantes du projet me permettront également de communiquer plus clairement vers l’équipe projet et concentrer notre attention sur celles-ci.

3. Respecter tous les engagements que j’ai acceptés

La première chose que je ferai pour réussir cette assertion est d’apprendre à dire « NON ». Il n’est jamais facile de dire non mais nous apprenons tous à la dure qu’il est encore plus difficile de respecter un engagement impossible.

Cela s’applique bien sûr pour définir le budget, les délais, des ressources … Cela s’applique aussi à comment je gère mes rapports aux autres : les membres de l’équipe auxquels je pourrais être tenté de faire des promesses qui sont au-delà de mon contrôle (particulièrement vrai dans les organisations matricielles), les sponsors qui peuvent décider de nommer un autre PM, les parties prenantes qui ont souvent des exigences conflictuelles et néanmoins compréhensibles, le boss qui subit la pression du top management…

Il sera aussi sage que j’ordonne ces engagements selon leur priorité pour mes clients et que nous soyons très clairs sur lesquels sont négociables si nécessaire.

Un de mes premiers managers disait souvent : « temps, coût, qualité : choisissez-en deux et laissez-moi un peu de liberté sur le troisième ».

4. Planifier le projet en entier dans le détail et l’exécuter par étapes

Je planifierai la totalité du projet à un niveau aussi détaillé que possible. Bien sûr, les prochaines phases peuvent être prévues avec une plus grande granularité mais il est important d’avoir un niveau raisonnable de détails pour la totalité du projet. Sans cela, il n’est pas possible de prévoir le temps, les dépenses et les ressources nécessaires pour le projet. Cela donne le ton et clarifie les livrables du projet pour moi-même et pour les membres de l’équipe ainsi que les parties prenantes et sponsors.

Il est aussi particulièrement utile d’avoir la vue complète avant d’accepter de réduire les délais ou travailler avec une limite de temps fixe ou répondre à une demande de réduire les ressources ou le budget. Elle me permet de comprendre où nous acceptons des compromis, les risques que cela crée et ajuster les attentes en conséquence.

L’exécution du projet bénéficiera presque toujours d’une livraison étagée des produits à fournir. Cette approche par étape permet à l’équipe de se concentrer sur une portée limitée; elle nous stimule pour terminer dans des délais plus proches de nous; elle construit la confiance en nos capacités et entre nous et le client car il peut commencer à voir et toucher quelques livrables; une boucle d’ajustement plus rapide est alors en place dans le cas où des changements seraient exigés; et cela permet des tests progressifs.

5. Connaître, communiquer et gérer le chemin critique

Le chemin critique est un bon outil de communication vers des équipes et la direction. Il présente une succession logique de tâches qui mènent à une conclusion couronnée de succès quand tous sont exécutés à l’heure. Il permet de se concentrer sur des tâches importantes et peut servir de base pour la décision des priorités.

Cependant, la plupart des outils de PM montrent seulement un chemin critique sur mon projet basé sur les ressources, les dépendances entre tâches et le progrès réalisé. J’ai appris au fil du temps qu’il peut y avoir de multiples autres activités critiques que l’outil ne détectera pas comme des tâches « sur le chemin critique ». Cependant, certaines pourraient mener à des retards plus grands si non complétées à l’heure. Un exemple sur l’un de mes projets était la tâche liée à la communication des objectifs d’une application informatique aux utilisateurs finaux dont le travail serait impacté par son introduction. Nous avions pléthore de temps pour le faire pendant la construction du logiciel et cela n’a demandé que quelques jours pour être exécuté. Cependant, parce que ce n’était pas fortement visible sur le chemin critique du projet (un faible effort, une date d’expiration éloignée), nous ne nous y sommes concentrés que très tard et ceci a causé des complications majeures car traité en mode « pompier » pas des plus efficaces.

Aussi, utilisez votre expérience, bon sens et votre compréhension holistique du projet plutôt que de faire aveuglément confiance au chemin critique proposé par l’outil que vous utilisez. Interrogez-vous sur le chemin critique proposé pour comprendre pourquoi certaines tâches que vous n’avez pas soupçonnées critiques y sont et d’autres que vos boyaux disent que vous feriez mieux de vous en inquiéter n’y sont pas.

6. Anticiper et gérer les changements

Commençons par le début: pour anticiper les changements, je commencerai par solidifier les exigences avec les commanditaires de manière très robuste pour établir une portée claire et un périmètre bien défini pour le projet.

Bien sûr, cela n’empêchera jamais que des changements justifiables soient demandés mais cela peut les limiter de manière significative Et, je mettrai en œuvre un processus clair, simple et rapide pour traiter les demandes de modification (y compris qui peut en soumettre, le processus de vérification, l’approche d’évaluation d’impact et les critères de décision).

Je garderai aussi à l’esprit que le processus ne fonctionne pas sous vide et que des changements à l’extérieur du périmètre du projet peuvent l’affecter. Ce pourrait être un changement d’un dirigeant qui est partie prenante du projet, un mouvement de la compétition, de nouveaux entrants ou des modifications du marché …

À propos, il pourrait aussi y avoir les changements positifs qui me permettent de produire de meilleurs produits plus tôt ou moins chers. Par exemple, ceci m’est arrivé avec un système de management des services de support nous développions pour une de nos régions et qui a été choisi pour être déployé dans le monde entier. Bien qu’il ait augmenté la portée du projet, les dépenses et les délais, le coût par utilisateur final de la solution a été très significativement réduit et cela a permis de fournir de meilleurs et plus homogènes services à plus faible coût.

7. Faire preuve de flexibilité

Bien sûr, j’ai appris comme tout chef de projet un certain nombre d’approches, méthodes et meilleures pratiques pour chacun des neuf domaines de connaissance spécifiques de management de projet proposés par PMI ® (Www.pmi.org) : intégration, contenu, risque, délais, coûts, qualité, ressources humaines, communications et approvisionnement.

Cependant, il est crucial que je reste ouvert et flexible sur lesquels appliquer à mon projet spécifique et son contexte. Par exemple, une approche de développement agile peut bien s’adapter au développement d’une nouvelle interface utilisateur Web la visualisation mensuelle d’indicateurs de performance, tandis qu’une approche en cascade peut être plus appropriée pour un système de gestion des ressources de l’entreprise.

Je serai en permanence à la recherche de nouvelles techniques, approches et outils.

Particulièrement ceux que d’autres membres de l’équipe peuvent avoir utilisés avec succès sur des projets précédents: Je chercherai toujours à apprendre et progresser. Par exemple, j’ai appris à mettre en œuvre des réunions de revue de problèmes quotidiennes courtes très productives pour des projets critiques comme cela avait été utilisé avec succès dans le passé par mon sponsor. Sur un projet différent, j’ai appris combien il est critique de comprendre la culture locale. J’ai essayé au départ et sans succès de diriger une session de brainstorming multi-niveaux hiérarchiques avec mes collègues japonais, avant de comprendre qu’il existe des approches plus appropriées pour obtenir leurs besoins et établir les priorités avec eux.

8. Ne pas badiner avec l’éthique de Chef de Projet

Depuis 1981, PMI ® a progressivement développé avec ses membres une déontologie et une conduite professionnelle pour les chefs de projet. Http://www.pmi.org/PDF/ap_pmicodeofethics.pdf

En tant que Professionnel de Management de projet certifié (PMP ®), je suis tenu de faire ce qui est juste et honorable. Cette déontologie et conduite professionnelle décrivent les attentes que nous avons de nous-mêmes et collègues praticiens dans la communauté mondiale de management de projet. Il articule les idéaux auxquels nous aspirons ainsi que les comportements qui sont obligatoires dans nos activités professionnelles et associatives.

Je continuerai à faire miennes ces valeurs que la communauté de management de projet mondiale définies comme les plus importantes : responsabilité, respect, justice et honnêteté.

9. Manager avec une attitude positive et collaborative

Je continuerai certainement à être sous pression de la direction et des clients pour livrer de superbes produits dans un temps réduit et avec des ressources limitées.

Cela ne m’empêchera pas de créer et entretenir une attitude positive dans l’équipe.

Je fournirai aussi un environnement collaboratif qui facilite les communications de l’équipe. Les outils sont là, nous devons seulement faciliter leur mise en œuvre et leur utilisation.

L’objectif est de construire une atmosphère qui reconnaît l’urgence, la pression, l’effort exigé de chacun d’entre nous et aussi qui montre la confiance en notre capacité commune à réussir. Les collaborateurs regardent le chef de projet comme tout leader, un peu comme un chef d’orchestre. Ainsi, son leadership positif donne le ton et influence la capacité de chaque joueur, la perception des clients et l’engagement des parties prenantes. Davantage de détails sur le Leadership de Projet.

10.  Se concentrer sur les personnes

Se concentrer sur les personnes : les membres de l’équipe que je développerai (voir la résolution 1), les clients et les dépositaires que je satisferai (voir 2, 3, 6), ma famille avec laquelle je passerai autant de temps que possible.

Je garderai à l’esprit qu’un projet est un effort provisoire alors que les rapports je construis pendant son déroulement dureront beaucoup plus longtemps.

Top 10 – 2009: Les articles les plus lus / Most often read articles

Le par mopertodans best practicesLaisser un commentaire

A mix of original articles and translations from other blogs.

Un panaché d’articles originaux et de traductions des meilleurs articles de PM lu sur le web.

1. Grand Winner: 7 attributes of leadership for the project manager

I have been so often asked “why are some project managers considered as administrators of projects while others were real leaders?” that I studied the question. […] I tried to synthesize attitudes, qualities and characteristics which I identified in the most brilliant of the project managers whom I know in 7 main attributes which make them exceptional leaders.

et En Français: https://dantotsupm.wordpress.com/2009/09/06/7-attributs-du-leadership-pour-le-chef-de-projet/

On m’a si souvent demandé ce qui faisait que certain chefs de projet étaient considérés comme des gestionnaires de projet alors que d’autres avaient une véritable dimension de leader que je me suis penché sur la question.

2. Comment le PM devrait-il gérer un dominateur pendant une réunion d’équipe ?

3. trucs et astuces avec MS Project – MS Project Tips

4. Modèles de Plan de Projet par Microsoft – MS Project Plan templates

5. astuces pour tirer le meilleur de vos formations en management de projet (et autres cours)

also often read in English: tips to get the best of your project management training (and any other class)

6. Diagramme de causes et effets – Ishikawa – Fishbone Diagram

7. gérer les conversations difficiles pour les Chefs de projet

8. avantages et inconvénients des diagrammes de Gantt / pros and cos of Gantt Charts

9. L’examen PMP en quelques mots – PMP in a nutshell

10. préparer un entretien d’embauche de chef de projet – preparing for a PM job interview