Why Agile projects fail ?

Sometimes Agile projects fail, below the 5 most common reasons :

1) Internal politics or HR conflicts

Agile projects are built on a collaboration principle. If there are conflicts in the team, or in the company, the Agile project is in trouble !

One possible root cause for team conflicts are undefined roles and responsibilities (most important are Product o

wner and Scrum master roles)

In doubt what these roles mean ? please, ask your Who makes a good product owner or a good scrum master and check this with your own agile project team.

Some tips here.

2) No Continuous Integration Environment and no Configuration Management tool

Setting up a Continuous Integration Environment is essential for everyone who wants to be Agile and work in short iterations (like with the Scrum technique).

The main objective for a such a system is to frequently build the source code committed by developers (each night for example). Each iteration is automatically built and tested as soon as possible integration errors.

This approach should also work with a strong Configuration Management tool.

3) Too much Expectations

Even if Agile project management is a best practice for executing your IT project, this cannot be used without preparing it. For example, classic methods such as WBS or Estimates calculation for building a realistic schedule and costs are still necessary before launching the project or program.

4) Operations are not Development (think Devops)

This is one of the most important causes of failure. Developing is fantastic 🙂 but you also have to take into account :

• Effective, collaborative and productive relationship between development teams and operation teams
• Deploying your project in an operationnal environment !

5) Methodology is bad interpreted 

Self learning is a good thing but sometimes, we can interpret methods, terms, roles.

Bad roles for a Product Owner or a Scrum Master could be worse than using a classic project management organisation.

Sometimes, companies who want to implement an Agile Project realize that they don’t know what to do with the old Management organisation. Then, to avoid internal conflicts, they prefer creating intermediate roles…

Adapt your company organisation before changing your project methodology !

And don’t forget, everyone in the organisation should work in the same way. Don’t mix Waterfall and Agile in the same project. It”s preferable to stay in waterfall method if your company is not ready to change.

Management Style !

Vous 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

Rise Above the Most Common Project Management Mistakes

A 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 !

Le 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

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

Portefeuille, Programmes et Projets

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