De nombreuses méthodes de management de projet – Many PM methodologies

Suite à une demande sur un forum LinkedIn, Marc Bonnemains, partage avec nous une liste de méthodes qui sont utilisées dans différents contextes métiers et pays à travers le monde.

Nous avons différentes méthodes de gestion de projet à ne pas confondre avec un corpus de connaissance comme le PMBOK, bien sûr.

  • Prince2
  • IPMA Compétence base line
  • APM Body of knowledge
  • GAPPS – Global Alliance for Project Performance Standards
  • La conduite de projets à l’IN2P3
  • HERMES – La méthode suisse de conduite de projets
  • Japanese Project Management – Project and Program Management for Enterprise Innovation (P2M)
  • IEEE Software Engineering Standards
  • ADePT Methodology (nouvelle approche)
  • Il existe aussi des méthodes de gestion de projet pour ONG – COTA
  • Peace Corps – Peace Corps Programming and Training Manual
  • SCALPS : Guide des projets scientifiques du CNES – Support méthodologique commun, il est destiné aux laboratoires, entreprises, industriels et aux responsables du CNES chargés du développement de produits. Il a pour objectif de leur apporter un soutien dans la conduite de projet, et de renforcer leur autonomie envers les agences spatiales.
  • Référentiel QUAPITAL-HERMES V1.2 – Issue de la méthode HERMES créée par l’Unité de Stratégie Informatique de la Confédération suisse (USIC), le référentiel QUAPITAL-HERMES est une solution globale personnalisée et optimisée pour le Luxembourg.
  • Méthode de gestion des risques de sécurité OCTAVE® – For an organization that wants to understand its information security needs, OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability EvaluationSM) is a risk-based strategic assessment and planning technique for security.
  • Différent outils méthodologiques élaborés et maintenus par l’ANSSI sur l’aide à la prise en compte de la sécurité dans les systèmes d’information. EBIOS – Expression des Besoins et Identification des Objectifs de Sécurité, PSSI – Guide d’élaboration de politiques de sécurité des systèmes d’information, TDBSSI – Guide d’élaboration de tableaux de bord de sécurité des systèmes d’information, GISSIP – Guide d’Intégration de la Sécurité des Systèmes d’Information dans les Projets, Guide relatif à la maturité SSI.
  • La conduite de projet informatique vue par le CNRS. Le CNRS étant toujours une référence en France, je vous invite à découvrir la méthodologie en conduite de projet que le CNRS préconise pour le domaine des Systèmes d’Information.
  • D’autres liens / other links : Papers, Links and Project Management Resources.

En « cascade » + RUP + Agile : Complémentarité plutôt qu’opposition

J’ai apprécié cet article où l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et plus récentes.

Le choix entre les méthodes « en cascade », RUP et agile, y dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dimension géographique.

Ce qui représente en soi, un bon exemple d’agilité dans le choix même de l’approche qui pourrait être une combinaison des trois méthodes selon les moments du cycle de développement.

Utilisez vous d’autres critères de choix de l’approche de développement?

En « cascade », RUP et Agile : quelle est la bonne méthode de développement logiciel  pour vous?

Article original de Serhiy Kharytonov, SoftServe © 2009

Http://www.executivebrief.com/software-development/waterfall-rup-agile/

Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mélange des stratégies de développement de logiciels afin de répondre aux besoins spécifiques de votre projet.

Malgré les signes de reprise dans l’économie, la réalité persiste dans le développement logiciel. La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible. Pour atteindre ces buts apparemment contradictoires, les développeurs cherchent à rationaliser la production avec les processus rapides, efficaces qui peuvent donner au client ce qu’il/elle veut en un laps de temps le plus court possible.

Ces faits et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel du passé, souvent appelé le modèle « en cascade », aux modèles plus itératifs et progressifs tels que « Rational Unified Process (RUP) » et « Agile. »

Les partisans d’Agile sont nombreux et il peut parfois sembler que des processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, des côtés négatifs et leurs environnements de projet favoris. Au bout du compte, la meilleure méthode ou le meilleur mélange de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, la culture business et l’environnement de développement.

En « cascade »

La programmation en « cascade » est un processus fortement structuré qui compte lourdement sur la planification initiale et un ensemble d’étapes séquentielles, prescrites qui coulent de l’une dans l’autre comme une chute d’eau. Chaque étape a typiquement son équipe propre d’experts et des jalons soigneusement préparés d’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète  avec des résultats qui sont fortement prévisibles.

Typiquement les étapes dans le développement en « cascade » sont :

  1. Recueil des besoins et rédaction du cahier des charges
  2. Analyse fonctionnelle
  3. Développement du code
  4. Intégration
  5. Test et mise au point
  6. Installation
  7. Maintenance

Le développement en « cascade » peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.

Les détracteurs disent que la « cascade » demande simplement trop longtemps et manque de la flexibilité – ou de l’agilité – requise pour le marché logiciel d’aujourd’hui et un environnement de développement en constant mouvement. Les projets qui suivent la méthode en « cascade » prennent typiquement des mois ou des années et au moment où ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut être des corrections onéreuses, explosant le budget.

RUP

Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin d’accommoder le changement et l’adaptabilité pendant le processus de développement.

Comme la « cascade », RUP a une série de phases et des jalons qui coulent l’un dans l’autre. Les phases consistent en :

  1. Création (« inception »), où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
  2. L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
  3. La construction, où le logiciel est construit et testé et la documentation de support est produite.
  4. La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.

RUP définit aussi les rôles et les activités de membres de l’équipe en détail et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que les grandes quantités de documentations requises pour chaque étape de la « cascade ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de directives, modèles, outils et autres articles pour assurer qu’ils partagent les mêmes langage et perspective sur le projet.

Alors que cela apparaît semblable au développement en « cascade » de prime abord, la plus grande différence du RUP est son approche de développement itérative, qui construit le produit dans plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin et d’architecture et l’exploration d’idées différentes, tandis que les itérations ultérieures essayent de rassembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.

Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours d’utilisateur.

RUP adresse bon nombre des critiques du développement en « cascade » et est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.

Les critiques disent que RUP n’est pourtant pas aussi rapide et adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial ou bien pour le Web 2.0 et les environnements Software-as-a-Service (SaaS) où on s’attend à des mises à jour fréquentes et des compléments de fonctionnalités.

Agile

Tandis que la « cascade » et RUP penchent vers la prévisibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, y compris XP et SCRUM, mais tous s’efforcent de mettre une version de produit basique mais fonctionnelle entre les mains du client aussi vite que possible.

Ils font alors suivre cette version par des versions successives qui ajoutent et changent des fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes sessions de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme la « cascade » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.

Plutôt que de dépendre de nombreuses équipes d’experts, le processus de développement Agile entier est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client, qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La collaboration en face à face constante est le but, avec le représentant du client utilisé comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à la « cascade » et même à RUP pour sortir quelque chose aussi rapidement que possible.

Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement de besoins et des défis compétitifs, qui sont les raisons de tant de partisans. British Telecom est fréquemment cité comme une société qui a utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont rapporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.

Mais même s’il est facile de tomber amoureux d’Agile, elle a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rendent le processus difficile à adapter à l’externalisation des développements, aux clients et développeurs géographiquement distribués, ou aux clients qui n’ont tout simplement pas la main d’œuvre, les ressources ou l’attention nécessaires.

Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas facilement aux clients qui veulent des contrats avec des évaluations fermes et des calendriers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec beaucoup de parties prenantes aux besoins  différents et néglige de prendre en compte du besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.

De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec la « cascade » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.

Le meilleur de chaque monde

Si Agile, RUP et des modèles en « cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret au développement logiciel réussi est de comprendre les trois processus dans le détail et sélectionner les parties de chacun qui conviennent le mieux à votre livrable et environnement particuliers. Puis, être agile dans l’approche même du processus, en regardant sans cesse sur ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux à vos circonstances actuelles.

Par exemple, si vous développez du logiciel SaaS ou Web 2.0 dans un marché fortement concurrentiel, alors vous ferez probablement le meilleur choix en penchant vers des méthodologies Agiles. SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour ajouter ou changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateur changeants vous voudrez probablement être capables d’apporter rapidement des changements.

D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou d’autres systèmes qui exigent un haut degré de conception et de certitude, alors il semble logique de commencer par la « cascade ».

Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui doivent être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière au recueil des besoins, à la définition du périmètre et du contenu au début, ainsi que des standards de navigation, et d’interface utilisateur.

Cependant, les développeurs peuvent tout de même utiliser des techniques Agiles pour présenter des prototypes fréquents et des modules progressifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de société – selon que ces équipes soient plus ou moins habituées à une telle collaboration. Quand la géographie est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.

Ce même mélange de techniques peut être utilisé dans un environnement d’entreprise externalisant le développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contact de suivi qu’il est possible pour votre projet, la culture de votre société et celle de vos partenaires de développement.

Choisir de partir sur des équipes auto-organisées ou une approche plus « top-down »  de management dépend vraiment du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leader qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins pour les itérations suivantes.

Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et environnements, ni même pour un seul. C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement. Bref, en choisissant entre Agile, RUP et en « cascade », adaptez le processus à vos besoins, plutôt que d’adapter votre projet au processus.

why quick fixes often lead to more trouble

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 ?

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)

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

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 ?

more good resolutions to build upon

Thank you to the numerous readers of the prior post on this topic and especially those who took the time to comment and propose these additional items. So, if you did not find appropriate resolutions for your specific situation in the prior list, here are a few more to consider…

11.  Mentor and coach upcoming PMs. Within prior resolutions 1. Develop team members and 10. Focus on people; it’s quite true that a specific set of persons we need to help are the upcoming and junior PMs. It can be as simple as asking them regularly how things are going on their project, which areas they find difficult, what’s eating up their time, what are their critical risks… And then providing them with few but valuable ideas, pointers, relevant materials to address their concerns, or offer a little bit of our time for discussion and bouncing off ideas they could have. I specifically say « few » because overwhelming them with advice, pointers, or questions, would be counter-productive based on my experience.

12.  Manage your Stakeholders. Another very valuable good resolution and not an easy one given the variety of stakeholders. A good starting point may be to decide to systematically spend some time at the beginning of each phase of the project to identify stakeholders who are not in the decision making nor management of the functions directly impacted by the project (as we’re likely to know these very well already). So, try to identify others that the project impacts and what exactly the impact could be on them. Then, review their relative power and influence in light of how they could react and plan how to enhance their support to the project and prevent negative responses.

13.  Manage the scope at any cost. No gold-plating for anyone. More on this in these posts Contents drive cost and schedule and How to write the statement of work.

14.  Anticipate, identify and manage risks. Let the key stakeholders be aware of all risks at all points of execution. Yes, I know, this sounds pretty obvious, but so do quite a lot of the other mentioned proposals.

15.  Ensure lessons learnt are captured and communicated. This is one I must admit is tough to keep on the list. As many fresh PMP®s, I started very enthusiastically, trying to do such sessions at the end of each phase and not only project closure. Preparing documents to communicate on the interesting findings, setting up sessions for review and sharing… However, it turns out that most people are not very interested in hearing the lessons from your project. Their perception often is that their project is unique, therefore different, and it is too much of an effort for them to try to understand how to apply your lessons to their environment. Nevertheless, if you have time, they are most willing to share their own lessons learned from their project with you… Having said that, this blog testifies that I continue to share as much as possible with others but may be in a slightly different manner.

16.  Define roles and responsibilities for each team member.

17.  Communicate effectively with all project team members, stakeholders, sponsors etc. Having a sound communications plan, acting on it and maintaining a high level of communication wins people over and keeps them onside. There will always be one or two tricky people though, but hey that’s part of life.

18.  Align all resources on a common goal, especially when dealing with resources from multiple departments, make sure everyone stays focused / committed on the same goal. It is very easy to loose resources from different departments as business needs evolve as the time goes on and resources get shifted / re-allocated.

19.  Do not take any good resolution at all (unless you’re truly committed to track your progress against these and achieve them successfully).

And, in case you would think that the initial proposed list of 10 good resolutions was too long:  several professional project managers came back to me indicating that these are simply the usual stuff to be done to be an acceptable Project Manager!

Back to basics?

Free test exams PMP – Jeux de questions gratuites pour PMP

any others to add to the list?

En connaissez-vous d’autres?

Since Jan 1, 2010 – Prince2 2009 exams

Prince2 refreshed its methodology last June and since the beginning of 2010, all exams are now against this new referential.

More information on Prince2 2009 Refresh highlights.

PRINCE2 Quick Links

Join the PRINCE2 Forum:Most active PRINCE2 online forum in Europe.

PRINCE2 Training options:Find out about the PRINCE2 qualifications available and how to get PRINCE2 certified.

PRINCE2 Newsletter:Keep up to date on PRINCE2 news with this monthly newsletter.

10 good resolutions for a Project Manager in 2010

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

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.

Mindmapping Software Blog

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

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

some cool and short tutorial videos about Web 2.0 and social networking in plain English

A blogger named Kareem Shaker from Dubaï has regrouped a set of short 3 minutes videos on most of the web 2.0 social collaboration tools. Happy viewing. Thank you Kareem.

Mieux comprendre et prévenir le stress

J’ai assisté à une excellente présentation (suivre ce lien et sélectionner l’image « stress ») il y a quelques jours au PMI France-Sud sur « Mieux comprendre et prévenir le stress ».

La présentation fut délivrée par Guillaume Pertinant de la société Havasu qui nous a parlé des sources du stress et de bonnes pratiques pour mieux le gérer et surtout essayer de le prévenir.

templates for project managers at ProTrain Canada

Free Templates for project manager

Business Case: To help you package your business case for the early phase of the project. It provides all the elements required to justify or not the investment in a new project

Project Charter Letter: A lot of people are wandering how to do a project charter. The format is not important as long as there is an official announcement that a project manager has been nominated. Here is a sample letter you could use to do that.

Project plan: The integration of all sub plans into one mother of a plan is a body of knowledge by itself. here is a model to help you do that.

Estimation: Estimating IT project tasks or deliverables in terms of time and cost is always as difficult as forecasting weather. here is a template to help you capture all the elements and break it down into manageable elements after.

Opportunity Assessment: When people have great idea, we dont want to shut them down but at the same time we need to know more then few words. This template will help you help the idea provider to structure his or her idea into a framework that will allow you later to analyse thsi idea to its full merits.

Feasibility Study: Here is a template that will allow you to strcuture a Feasibility study that will provide answers to key business questions such as, why do we invest in this project, what are the tangible benefits, what are the risks, what are the possible solutions , what is the recommend solution etc..

Change Analysis: When change start coming at us we need to be structured in our analysis process to ensure that we dont oversea anything. this template will help you to structure the analysis.

Risk Management

Statement of Work:
This template could be use internally with marketing or sales department. It is a must to capture properly the requirements to ensure that we translate them into deliverables. If you dont tranlate them well to your own supplier then dont expect them to read your mind.

Status report

Earned Value report: Earned value calculation could be difficult or painful to do. Here is a template developed by a PTC contributor to help him track his CPI and SPI.

and many more…

an experience of the advantages of project portfolio management

During the implementation of a portfolio management approach for information technology projects at Equant (a few years ago), I noticed that the most important benefits for us were the following ones…

read the full article at: http://bit.ly/3w7GMB

What is your own experience?

Planifier des réunions / agreeAdate

Schedule conference calls, meetings and events the easy way.

agreeAdate saves you time and money by avoiding telephone and email tag to find when people are free. Just send invitations to collect availability and then make your choice from the results.

Free and easy to use with reminders, confirmations, ability to provide conference call details, understanding timezones… What else ?

Document Summarization / Résumer rapidement un document Anglais

great summary logohttp://www.greatsummary.com/

Un site utile pour réaliser rapidement des résumés certes approximatifs mais qui peuvent néanmoins vous permettre de décider si vous souhaitez ou non investir le temps nécessaire à la lecture complète du document (ou de la page web).

Quickly get the gist of a document, webpage, or any text selection of your choice. Identify the key topics of a document while eliminating redundant information

dictionnaires Larousse en ligne Français et bilingues (4) pour vos traductions !

laroussehttp://www.larousse.fr/dictionnaires

5 dictionnaires de français pour une meilleure maîtrise de la langue !

  1. Dictionnaire de français: 135 000 définitions et 6 000 articles pour déjouer tous les pièges de la langue
  2. Dictionnaire des synonymes et contraires: 92 000 synonymes et 29 000 contraires
  3. Dictionnaire des expressions: 34 000 expressions
  4. Dictionnaire des homonymes:  15 000 homonymes
  5. Dictionnaire des citations: 9 000 citations

Plus: toutes les conjugaisons: 9 600 verbes conjugués à tous les temps et tous les modes

Et 4 dictionnaires bilingues:

  • Anglais
  • Allemand
  • Espagnol
  • Italien
  • Dictionnaire de français

    135 000 définitions et 6 000 articles pour déjouer tous les pièges de la langue

  • Dictionnaire des synonymes et contraires

    92 000 synonymes et 29 000 contraires

  • Dictionnaire des expressions

    34 000 expressions

  • Dictionnaire des homonymes

    15 000 homonymes

  • Dictionnaire des citations

    9 000 citations

  • Toutes les conjugaisons

    9 600 verbes conjugués à tous les temps et tous les modes