Category Archives: Program Management

Management Style !

by

ManagementVous ne trouverez dans cet article aucun rapport avec la chanson Coréenne qui vient de battre tous les records “de vues” sur Youtube (on peut cependant souhaiter à k4pm.com autant de succès :-)). Juste le titre qui m’a fait penser qu’un rappel sur les styles de management avait sa place sur ce blog !

On recense 4 styles de management. Chacun de ces styles est applicable en fonction de la situation, du projet, de la personne à encadrer.

Le style persuasif :

Le Manager est le “Guide”, il fait preuve d’un fort charisme. Son attitude envers les autres est l’écoute. Le résultat est une équipe soudée.

Le style participatif :

Le Manager est au centre; les informations lui remontent. Il associe les personnes qui l’entourent aux décisions. L’équipe est motivée et toute ensemble focalisée sur l’objectif. Attention, cette méthode est chronophage.

Le style délégatif (hands off approach en anglais) :

Le Manager définit les objectifs et laisse l’autonomie nécessaire à l’équipe pour les atteindre. Il ne reste présent qu’en cas de support. Bien que cette méthode favorise l’autonomie, le Manager doit être vigilant à ne pas trop ‘se couper’ de son équipe. Attention à ce que la remontée de problème vers le Manager ne soit pas trop tardive…

Le style directif (dictatorial style en anglais) :

Le Manager impose ses décisions avec fermeté. Le climat généré dans l’équipe est plutôt froid. Ce style est frustrant pour l’équipe et peut aller jusqu’à annihiler toute créativité.

Patrick

No more risks in your project management

by

RisksRisk Management is one of the virtues a project manager should have ! Of course, you can read PMBOK / Chapter 11 but not only…

I gonna list below the 9 necessary steps.

But before, remember that : Criticity = Probability x Impact

Step 1 : Build a risk registry

Archive in the Project Management Information System (Microsoft Sharepoint for example), a log for each identified risk with the following arguments :

  • Risk identifier (unique)
  • Risk description
  • Probability (unlikely, possible, highly probable)
  • Impact (low, medium, high)
  • A responsible for the risk management
  • Status
  • End-of-life estimated for the risk

Step 2 : Identify the risks with your team

The project manager is not alone ! risk management is a “core team’s job”

Each part of the project should be analyzed (scope, schedule, resources, budget, quality, sponsors, environment, stakeholders, providers, etc…)

Step 3 : Identify the opportunities

Even if a risk is frequently a threat, don’t forget it could be an opportunity. In this case, project manager has to explore it.

Step 4 : Analyze the root cause

Understanding the root cause will help the project manager to manage better the risk in order to reduce is criticity. Be careful if the risk become an issue !

Step 5 : Estimate the Impact

Project Manager has to build a “scoring grid” for managing the risk. This tool will help the team to quantify and classify the risks in the project.

Step 6 : Estimate the Probability (likelihood)

Same method as previous topic but for estimating the probability that this risk occurs.

Step 7 : Assign a responsible

Assigning a responsible will help the project manager to delegate the risk management to someone more skilled with the risk’s technical cause.

Step 8 : Monitor the risks

Reviewing the risk in project comity will help the project manager to estimate the total amount of the risk in its project. It’s also a good opportunity for updating the global risk status.

Step 9 : Communicate ! (again and again :-))

More than 80% of project management activity is communication. Then, communicate on risks identified and associated action plans !

Patrick

Note : same article in french here

Rise Above the Most Common Project Management Mistakes

by

business-man-mistake-whoopsA new year is upon us, so let’s take the opportunity to review some of the most common mistakes project managers make and decide to rise above them in 2013.

1. Underestimating your project
When you estimate a project or feature, it is very tempting to look at the sunny-case scenario and only provide best case estimates – especially if you work with a new team who is eager to please. It is also a common mistake to miss out important activities such as management overhead, documentation, rework and training. Contingency is another element which is often left out. The end result, unfortunately, is that the project runs out of money before all of the products are delivered. To read more, go to guidelines for estimating project effort.

2. Poor understanding of the detailed requirements
Many project managers have a superficial understanding of the product’s they need to deliver and how these products fit into the client’s business. They leave requirements gathering to the business analysts, which makes them vulnerable and dependent on subject matter experts for decision making and advice. It is true that you don’t have to be the expert in the domain, but you need enough knowledge that you can successfully steer the project and make effective decisions around risks, issues and quality reviews.

3. Focusing on the urgent; not the important!
We all know that project managers can be insanely busy. Busy dealing with urgent issues, defects and interpersonal conflict. But the busier you are putting out fires, the less time you will have for the really important activities such as planning, building relationships, understanding your client’s business,
motivating your team, reviewing quality etc. The reason you’re likely to spend most of your time on the urgent, is that you have not invested enough time in building up your team to handle the low level detail so that you can be freed up to focus on that which is really important.

4. Failure to properly initiate your project
We all know that failing to plan is planning to fail, but even so, many project managers jump straight into project execution without knowing what they need to deliver, how they will do it, or how much it is likely to cost. I am not an advocate of a waterfall methodology, but even in agile a firm foundation is necessary before you start to commit resources and funding. You need to fully understand what you are building, why you are doing it, how and when you will do it, and how much it is likely to cost. Find out how to initiate and plan your project here.

5. Not keeping your promises
As the project manager it is your job to keep track of the projects activities, risks and issues, and to convey the project’s status honestly and accurately to your client. If you over-promise or say you will do things without doing them, your reputation is at stake and your client will stop believing in you. To build strong relationships with your customer and your team, and to deliver your project successfully, you MUST have accurate information at hand before you make a commitment. This is true for even the smallest of promises.

6. Failure to involve the end users
One of the best ways to ensure that your project is heading in the right direction – and that it will meet your client’s needs – it to gradually show the users what you are building and to listen to the feedback they provide. Unfortunately many project manages fail to do that. They gather the user’s requirements, and then go off and build the product in isolation without incorporating regular demos, prototypes and reviews. If you manage your project in such a static way, you run the risk of building a product which may be what your client wanted, but not what they truly needed.

To improve your project management skills, and learn how to overcome the most common challenges project managers face, study The Project Management Workbook.

Published with the kind authorization from Susanne Madsen
http://www.susannemadsen.co.uk

Pour un management de projet sans risques !

by

RisksLe management de projet par les risques est une des vertus que doit avoir un Chef de projet. Il faut s’armer d’une bonne dose de méthodologie (cf chapitre 11 du PMBOK® Fourth Edition) mais pas seulement.. Je vais lister ci-dessous les étapes nécessaires !

Pour rappel : Criticité = Probabilité x Gravité

1) Construire le registre des risques

Archiver dans le système d’information de votre projet (Sharepoint par exemple), un registre contenant pour chaque risque identifié :

  • l’identifiant unique
  • une description
  • la Probabilité d’occurrence (faible, moyen, fort)
  • la Gravité (faible, moyen, fort)
  • le porteur
  • le statut
  • la date de fin

2) Identifier les risques avec votre équipe

L’identification des risques ne se fait pas seul, c’est le travail de la “core team” du projet. L’identification passe par une revue de tous les secteurs possibles du projet (périmètre, planning, ressources, budget, qualité, sponsors, environnement, fournisseurs, etc..)

3) Identifier les opportunités

Ne pas oublier que même si bien souvent un risque est une menace pour le projet, il peut être aussi une opportunité. Dans ce cas, il convient de l’exploiter 🙂

4) Analyser la root cause

Comprendre la cause vous permettra de mieux aborder ce risque et potentiellement en réduire sa Criticité. Le chef de projet doit fait tout son possible pour éviter que le risque ne se transforme en problème (issue) pour le projet.

5) Définir l’impact

Dès le début du projet, le chef de projet va créer “une grille de scoring” pour les risques. Cela permettra de quantifier sans doute les risques qui seront identifiés par l’équipe.

6) Définir la probabilité d’occurrence

La même démarche que pour l’impact sera initiée au début du projet et consignée dans le Plan Projet.

7) Assigner un porteur

Tout risque doit avoir un porteur qui doit s’attacher à réduire au minimum (voir faire disparaître) le risque pour le projet.

8) Organiser des revues régulières

Des revues régulières (en Comité Projet par exemple), permettrons au chef de projet de considérer si l’ensemble des risques sur le projet sont à la hausse, à la baisse ou stagnent.

9) Communiquer et……communiquer !

80% de l’activité du chef de projet est la communication.
Donc, communiquez sur les risques identifiés, communiquez sur les plans d’actions, communiquez !

Patrick

Note : la traduction anglaise ici

Gérer les projets avec des ressources asiatiques

by

Travailler dans un environnement multi-culturel n’est pas chose aisée. Je rentre tout juste d’un voyage professionnel en Asie et je me rappelle encore un podcast écouté voilà plus d’un an sur le management de projet impliquant des ressources chinoises. Le billet qui suit ne s’applique pas qu’à la Chine mais également aux autres pays asiatiques avec lesquels j’ai pu travailler (tels que la Corée, Taiwan, Singapour, l’Indonésie). Cela est donc une sorte de “leçon apprise” au cours de ma dernière expérience professionnelle.

La rencontre :

Tout d’abord commençons par la présentation, car c’est dans l’ordre des choses lors d’une première rencontre 🙂 – Avant le tour de table traditionnel, les participants se rencontrent (debout) et échangent leurs cartes de visites selon un processus très précis :

    • recevez à deux mains et prêtez y attention en lisant et répétant le nom et prénom de la personne qui vous l’a donné;
    • après un traditionnel ‘nice to meet you’, donnez votre carte à deux mains et déclinez votre identité en n’oubliant pas d’indiquer votre rôle dans l’organisation.

Ne soyez pas étonnés, les chinois et taiwanais prennent des noms anglo-saxons pour faciliter le dialogue avec les occidentaux. Ces noms ne figurent pas dans leurs papiers d’identités, ils ne servent que pour le business. Amusez-vous à leur demander leurs vrais noms et à les prononcer, cela sera apprécié !

Si vous devez travailler régulièrement avec un pays asiatique, il est bien apprécié d’avoir une carte de visite en 2 langues (recto : anglais / verso : celle du pays avec lequel vous travaillez). Préférez également des cartes de visites plastifiées car les plus classiques en papier ‘gondolent’ sous l’effet de l’humidité des pays asiatiques.

La relation humaine :

    • Les asiatiques ont besoin de connaître les personnes d’abord plutôt que les sujets. L’importance pour eux étant la valeur de la personne avant toute autre chose. Ils vont souhaiter vous connaître, déjeuner ou dîner avec vous, vous donner des cadeaux. Appréciez ces gestes comme une ouverture et non comme une tentative d’acheter quelqu’un.
    • Ne pas perdre et ne pas faire perdre la face, éviter la confrontation, trouver toujours le consensus. Ne pas agresser les personnes car cela est considéré comme une perte de l’honneur ! ne pas non plus perdre son sang froid … cela est totalement décridibilisant.
    • Soyez patients: c’est une vertu ! faites également attention à la notion de temps qui est différente de celle des européens ou des anglo-saxons (ajoutez des marges dans vos plannings et gérez les risques de glissement).

Le maniement de la langue anglaise : il n’est pas étonnant d’avoir dans la salle de réunion des personnes qui ne parlent pas anglais mais qui assure un support technique à ceux qui dialoguent avec vous.

A vous de nous faire partager votre expérience, selon l’intérêt, j’ajouterai la bonne pratique au post ci-dessus. D’avance merci pour vos contributions.

Patrick

Recueil d’exercices et de formation PgMP gratuits

by

Bonjour,

Si comme moi vous êtes en train d’étudier pour la certification PgMP ou si vous êtes intéressé par le Management de Programme, vous trouverez ci-dessous un lien pour télécharger les premières pages en PDF de l’excellent recueil d’exercices et de formation PgMP écrit par Jean Gouix et Martial Bellec.

Cliquez-ici pour télécharger le pdf.

Si vous souhaitez la version complète, vous pouvez la commander en cliquant sur l’image ci-dessous :

Bonne lecture 🙂

Patrick

Les 5 phases d’un Programme

by

Un Programme s’articule autour de 5 phases (traduction française du Standard for Program Management — Second Edition – PMI) :

  • La préparation du Pré-Programme (Préparation)
  • L’initialisation du Programme (Initiation)
  • La définition du Programme (Setup)
  • Les livrables du Programme (Deliveries)
  • La clôture du Programme (Closure)

Les durées de ces phases sont variables et dépendent directement du périmètre du Programme.
Chacune de ces phases est validée par un point de passage formel qui valide les livrables produits.

1) La préparation du Pré-Programme

  • Comprendre et identifier les gains stratégiques du Programme,
  • Préparer le planning initialisant le Programme,
  • Définir les objectifs du Programme et les mettre en cohérence avec les objectifs de l’entreprise,
  • Préparer un ‘high level business case’ démontrant la justification du Programme,
  • Convenir d’une série de jalons programme clefs, qui permettront de s’assurer que le programme est conforme aux attentes.

2) L’initialisation du Programme

L’objectif principal de cette phase est de définir en détail comment le Programme sera organisé, piloté, et quels seront les principaux bénéfices attendus.

3) La définition du Programme

Cette phase finalise la charte programme et défini les bases du programme. Elle indique également comment le programme sera piloté et ses principaux livrables.
Cette phase se concluera par l’approbation du Plan de Management du Programme

4) Les livrables du Programme

Cette phase représente l’exécution du programme et notamment le suivi des livrables des projets qui le compose. L’équipe en charge du pilotage du programme sera vigilante et s’assurera que :

  • Les projets du programme délivrent conformément aux attentes définies
  • Les ressources partagées, les activités en commun sont nominalement coordonnées
  • Les risques soient correctement identifiés et suivis
  • Les problèmes connus ont des actions correctives prévues (porteur + date)
  • Les demandes de changements et activités non prévues soient actées ou pas
  • La communication auprès des parties prenantes soit effective

Le responsable du programme s’assure de l’alignement général, les chefs de projet ne s’occupant que de leur activité.


5) La clôture du Programme

Cette phase marque la fin du programme est généralement terminée suite à la livraison du produit accepté par le client.
Les activités réalisées durant cette phase sont :

  • La revue des livrables avec les parties prenantes
  • Le démantèlement de l’organisation, des moyens, et la libération des ressources impliquées
  • La compilation des leçons apprises
  • L’archivage de la documentation afin de pouvoir la réutiliser pour les programmes futurs

Portefeuille, Programmes et Projets

by

K4pm.com est le site de la connaissance en Management de Projet. Aussi, après avoir publié 3 articles, je me dis qu’il est important de rappeler les fondamentaux 🙂 – voici que ce dit le PMI®.

Qu’est-ce qu’un Portefeuille de Projet :

“c’est une collection de composants (Portefeuilles, Programmes, Projets) regroupés de façon d’une part à faciliter le pilotage et d’autre part à atteindre les objectifs. Les Programmes et les Projets au sein du portefeuille n’ont pas nécessairement un lien ou de dépendances entre eux”

Qu’est-ce qu’un Programme :
“c’est un ensemble de projets qui ont un lien entre eux. Ils sont démarrés pendant le cycle de vie du Programme et pilotés de façon coordonnée. Le Responsable du Programme coordonne les efforts entre ces projets mais ne les pilote pas directement”

Qu’est-ce qu’un Projet :
“Un projet est un effort provisoire avec un commencement et une fin (d’habitude contraint de temps et souvent contraint en budget ou dans la fourniture de livrables), entrepris pour atteindre des buts uniques et des objectifs”

Differences between projects, programs and portfolios