Chef de projet ou Gestionnaire de projet ?

Quelle est la traduction de project manager en français: chef de projet ou gestionnaire de projet? Cela a des connotations très différentes.

L’image du chef est celle du leader, du meneur d’hommes, qui fait avancer les choses. L’image du gestionnaire rappelle celle d’un comptable ou d’un bureaucrate procédurier empêtré dans les fiches et les rapports.

Quand il faut choisir une traduction pour project manager, il n’est pas étonnant qu’au pays de Cyrano de Bergerac on préfère le panache du chef à la grisaille du gestionnaire. Mais il faut savoir que nos amis québécois traduisent généralement project manager par gestionnaire de projet.

Alors que faut-il en déduire sur le rôle de project manager: chef ou gestionnaire ?

Dans une entreprise, il y a un PDG et un DAF (directeur financier), donc un chef et un gestionnaire. Mais ce modèle est difficilement applicable à un projet standard qui verrait ses coûts fortement augmentés.

D’ailleurs dans les référentiels de gestion de projet, il n’y a que le rôle de chef de projet. On remarquera avec ironie qu’on parle de gestion de projet faite par un chef de projet. L’ambiguïté est réelle.

L’idéal serait d’avoir un chef-gestionnaire pour chaque projet. Mais cet idéal se heurte à une réalité. En plus du manque de temps pour tout faire ou de la difficulté à acquérir des compétences très différentes, c’est avant tout un problème de profil psychologique. La mentalité d’un chef n’est pas celle d’un gestionnaire et inversement. Trouver une personne avec les 2 profils relève donc de la gageure.

Dans les faits, les chefs de projet font généralement le choix d’être des chefs et beaucoup moins des gestionnaires. Cela permet d’assurer que le projet avance dans la bonne direction. Mais cela se fait au détriment du suivi de projet engendrant l’identification tardive des écarts et par voie de conséquence d’importants dépassements, voire l’arrêt total du projet.

Le PMBoK identifie pour ce rôle double de chef-gestionnaire 47 processus différents. 47 processus pour un seul rôle! Absurde, non?

Quelles solutions à ce problème de rôle double de chef-gestionnaire ?

Une première piste serait d’appliquer les principes du Lean à la gestion de projet, supprimer les processus inutiles ou étaler la charge avec du juste-à-temps par exemple.

Une deuxième piste serait de définir plusieurs rôles ou de déléguer certaines responsabilités à l’équipe, à l’instar d’approches agiles comme SCRUM.

Une troisième piste serait d’outiller et d’automatiser les processus du gestionnaire, et éviter les «moulinettes» maison à base de feuilles Excel. Notez au passage qu’il est bien plus facile d’automatiser la gestion que d’automatiser le travail d’un chef.

Voilà les idées qui ont inspiré le logiciel de gestion de projet TimePerformance pour permettre aux chefs de projet d’être de bons gestionnaires sans effort.

Et vous, avez-vous d’autres idées à proposer ?

Anti-pattern agile: le manque de transparence

locked folderLa plupart des retours d’expérience à propos de la mise en place de l’Agilité dans les organisations font apparaître un obstacle majeur: la transparence ne fait pas partie de la culture des organisations.

Pire, la transparence est le plus souvent découragée. On préfère faire bonne figure en toute occasion, quitte à minimiser les problèmes, afin de ne pas être injustement classé parmi les messagers porteurs de mauvaises nouvelles. Cela engendre le syndrome du projet pastèque, rouge à l’intérieur et vert à l’extérieur.

Or c’est justement sur la transparence, ou plus exactement sur le marché implicite «confiance contre transparence», que repose la démarche Agile. Grâce à elle, la collaboration entre le Métier et l’équipe de développement est beaucoup plus efficace, car elle est directe, peu formalisée dans des documents ou ralentie par des processus (de validation ou autres).

Pour passer à l’Agilité, il y a un changement de culture à opérer au niveau de l’organisation tout entière.

Les équipes de développement, et les chefs de projet en particulier, doivent désapprendre la crainte de se faire taper sur les doigts à chaque annonce de contre-performance ou de difficulté. Ils doivent trouver un courage nouveau pour communiquer les éventuelles mauvaises nouvelles le plus tôt possible. Cela permet à tous de prendre les bonnes décisions au meilleur moment. Le Management doit encourager cette transparence et associer la contre-performance à de l’apprentissage. 

Quant au Métier, il doit s’associer à l’équipe de développement et quitter le mode de collaboration client-fournisseur. S’associer implique de ne former qu’une seule équipe et de participer à la résolution de tous les problèmes, y compris techniques. Cela passe par une acquisition d’un minimum de connaissances techniques sur le projet et par la recherche active du meilleur compromis entre valeur métier et faisabilité. Un gain supplémentaire non négligeable pour le Métier sera d’en retirer au final une bien meilleure compréhension de son produit ou de son outil.

Les équipes sont-elles prêtes à faire part de mauvaises performances éventuelles ? Le Management pénalise-t-il les mauvaises performances sans distinction ? Le Métier a-t-il envie de s’impliquer dans la technique ? Les réponses à ces questions sont essentielles pour démontrer un environnement propice au développement de la valeur Transparence, indispensable à la démarche Agile.

Quel rôle pour les chefs de projet dans Scrum ?

La méthode Scrum définit 3 rôles. Celui de chef de projet n’en fait pas partie. Beaucoup en déduisent qu’il n’y a plus de chef de projet avec Scrum. Certains s’en inquiètent en se demandant ce que vont devenir les chefs de projet lors du passage à Scrum.

Dans Scrum, le «chef de projet» est le Product Owner

Le chef de projet est la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.

Mener à bien un projet signifie de livrer de la valeur tout en respectant un budget et des délais.

C’est aussi la mission du product owner.

Le product owner est le responsable du backlog produit. Il priorise les éléments et leur associe une valeur business. Il gère aussi le release backlog qui détermine les délais et le budget du projet. Il a aussi le pouvoir d’arrêter le projet lorsqu’il juge que le ROI est insuffisant. 

Ce qui change avec Scrum

Certaines fonctions dévolues traditionnellement au chef de projet sont déléguées à d’autres personnes.

Il n’y a plus de management d’équipe

Dans Scrum, l’équipe s’auto-organise et s’autogère à l’aide d’un facilitateur, le Scrum Master. Il n’y a donc plus de management hiérarchique.

La gestion de la qualité

Le Scrum Master est responsable du respect du processus de développement et des normes de qualités.

C’est l’équipe toute entière qui est responsable de la qualité du produit.

Le découpage technique du projet et les estimations

L’expertise technique est du ressort de l’équipe. C’est elle qui identifie les tâches et estime la charge de travail.

Les bénéfices de l’approche Scrum

Le fait de déléguer une partie de ses fonctions à d’autres personnes peut être vu comme une très bonne chose.

Le chef de projet est traditionnellement surchargé du fait de ses multiples tâches: gestion de l’équipe, contact client, planification, gestion des coûts, gestion des anomalies…

De plus, certaines responsabilités peuvent amener à des conflits d’intérêt. Par exemple, la recherche de réduction des délais et des coûts peut inciter à sacrifier la qualité du produit.

Enfin, le rôle traditionnel de chef de projet peut exiger des compétences très différentes (communication, expertise technique, négociateur, écoute client, gestionnaire, leadership). C’est pourquoi on trouve souvent des descriptions de poste de chef de projet qui ressemblent à celle d’un mouton à 5 pattes.

Conclusion

La mission essentielle du chef de projet vis-à-vis de l’entreprise est confiée au Product Owner. Il n’est pas le chef d’une équipe mais le titulaire d’un projet ou d’un produit qu’il incarne.

Les chefs de projet qui deviennent product owners verront  leur (sur)charge de travail diminuée et pourront se concentrer sur la création de valeur métier.

Par contre, le management d’équipe disparaît. Le concept de « chef de projet technique » ou de team leader n’a pas d’équivalent dans Scrum. C’est un réel problème pour les personnes avec ce type de profil. Une reconversion en Scrum Master n’est pas forcément possible dans la mesure où cela requiert un type de personnalité très différente de servant leadership et non de chef. Les autres choix sont d’aller vers l’expertise technique, en espérant que celle-ci soit reconnue à sa juste valeur, ou vers le fonctionnel pour devenir product owner.

La méthode de la chaîne critique

chaine critiqueSelon ses adeptes, la méthode de la Chaîne Critique permet de réduire les délais par 2, de diminuer les coûts et d’améliorer grandement le taux de réussite des projets.

Ces promesses ne sont pas vraiment nouvelles mais il est toujours intéressant d’étudier les différentes approches. Comment cette méthode s’insère-t-elle dans le macrocosme des méthodes de gestion de projet ?

Une alternative à la technique du Chemin Critique

La Chaîne Critique est une technique de planification et de suivi des délais, qui remplace avantageusement la technique du Chemin Critique.

Le principe est le même: prendre en compte les contraintes pour déterminer la durée minimale du projet et les tâches critiques pouvant impacter cette durée.

Les 2 principaux ajouts de la Chaîne Critique sont:

  1. la prise en compte des limitations en ressources ou en compétences (en plus des dépendances entre les tâches). On parle alors de chaîne critique pour la distinguer du chemin critique.
  2. la mise en place de tampons (buffers), c.-à-d. des réserves de temps, dans la chaîne critique et les chaînes secondaires.

Si l’intérêt du premier point va de soi, celui des tampons méritent quelques explications.

Les tampons remplacent les marges de délai qui sont prises traditionnellement au niveau de chaque tâche lors des estimations. Cette approche a les avantages suivants:

  • Eviter de consommer inutilement les marges de délai au niveau des tâches. En effet, la loi de Parkinson observe que le travail s’étale de façon à occuper tout le temps alloué pour la tâche. Ainsi les réserves de délai au niveau des tâches sont systématiquement consommées.
  • Visualiser et de maîtriser les marges de délai. La séparation de l’estimation de la durée des tâches  et des marges de sécurité permet de mieux visualiser ces dernières. Cela permet de palier la multiplication de marges prises par les différents acteurs du projet.
  • Un nouvel indicateur pour surveiller les délais. L’indice d’utilisation du tampon permet de visualiser le niveau des réserves de délai. Une alerte est levée lorsque le niveau global d’utilisation dépasse l’avancement réel (= sur-utilisation de la réserve).

Les tampons sont définis au niveau des chemins, critique et secondaires, définis par le réseau de dépendances entre les tâches.

Le tampon principal, appelé tampon projet, est celui placé sur la chaîne critique. C’est celui à surveiller en priorité.

Ce tampon projet est une réserve non négligeable puisque l’auteur de la méthode, Eliyahu M. Goldratt, recommande une réserve de 50% de la durée de la chaîne critique. Cela revient donc à ajouter 50% de délai par rapport à la durée minimale.

Enfin, la méthode recommande d’utiliser un système de compte à rebours pour avertir les personnes du démarrage prochain de leurs tâches pour qu’elles démarrent à temps.

Notre avis

Nous préférons rester prudents vis à vis des résultats fournis par les études faites sur les bénéfices d’une méthode par rapport à une autre. Comme pour les méthodes Agiles, ces études sont souvent commanditées par ceux qui y ont un intérêt; et l’interprétation des résultats nécessiterait de se pencher sérieusement sur la validité de l’étude.

Concernant la promesse de réduction des délais, les promoteurs de la méthode partent du postulat que les délais sont systématiquement multipliés par 2 du fait du cumule des marges. Ce postulat nous semble hasardeux et ne correspond pas à notre expérience dans l’informatique. Au contraire, les délais initiaux sont souvent optimistes du fait des nombreuses inconnues du projet ou des pressions exercées pour gagner l’affaire.

Quant à la réduction des coûts, elle ne peut venir que d’un meilleur déroulement du projet puisque la méthode ne s’intéresse qu’aux délais.

Ceci étant dit, nous considérons que la méthode de la chaîne critique propose des améliorations importantes par rapport à la technique du chemin critique et nous semble nettement supérieure. D’une part, la prise en compte des contraintes sur les ressources est essentielle; d’autre part l’idée des tampons (buffers) est excellente.

Notre avis est que la méthode de la chaîne critique devrait supplanter celle du chemin critique.

Avec la chaîne critique, les délais annoncés devraient être mieux respectés du fait d’une meilleure gestion des marges. Notons au passage que le délai prévu pour le projet calculé selon cette méthode est d’au moins une fois et demie supérieur à la durée calculée selon le chemin critique du fait du tampon projet et de la prise en compte de nouvelles contraintes. C’est donc aussi plus facile à respecter 😉 .

Du fait de la similarité des promesses, nous avions cru initialement à une nouvelle approche dans le prolongement de l’Agilité ou du Lean. En fait, c’est le contraire. Cette méthode s’inscrit totalement dans la démarche traditionnelle en allant encore plus loin dans la planification.

Le champ d’application de la chaîne critique est donc bien différent de ceux des méthodes agiles et du Lean.

Références:

https://fr.wikipedia.org/wiki/Méthode_de_la_chaîne_critique

http://www.chaine-critique.com/fr/La-methode-en-action-4.html

Valeur Business ou Valeur Acquise ?

La volonté de maximiser la valeur business est une bonne pratique de gestion de projet, tout comme la technique de la valeur acquise. Ces deux concepts de valeur reposent sur des principes de valorisation de projet différents: l’un à partir des bénéfices, l’autre à partir des coûts. Faut-il pour cela les opposer ?

Récemment, nous avons présenté la technique de la valeur acquise à des managers d’une SSII. Après nous avoir écouté poliment pendant quelques minutes, un des interlocuteurs nous rétorque:

« Vous savez, nous, nous sommes agiles, la seule valeur qui nous intéresse c’est la valeur business !»

Voilà le nouveau mot à la mode: la Valeur Business.

Que les approches Agiles mettent en avant la maximisation de la Valeur Business, c’est très bien. Mais cela doit-il empêcher d’être par ailleurs un bon gestionnaire ? Et pour cela, il n’y a qu’une technique, celle de la Valeur acquise, approche agile ou non.

Valeur Business

La valeur business est juste un autre terme pour désigner les bénéfices attendus du projet ou du produit. Ce concept n’a donc rien de nouveau. Ce qui change avec l’Agilité par rapport à l’approche traditionnelle, c’est la possibilité de faire des modifications afin de maximiser la valeur business en cours de projet.

La valeur business permet de justifier le projet et de prioriser les items.

Continuer la lecture de « Valeur Business ou Valeur Acquise ? »

Le rôle du Product Owner dans SCRUM

Voici une excellente vidéo de Henrik Kniberg qui explique en 15 minutes le rôle du Product Owner dans Scrum.

Henrik Kniberg est aussi l’auteur de fameux Scrum and XP from the Trenches (téléchargeable gratuitement).

La vidéo est en anglais. Le texte est disponible sur le blog de Crisp.

Gestion de projet 2.0

Voilà plusieurs années que la vague 2.0 a atteint le monde de l’entreprise, d’abord par ses technologies (Web 2.0, Virtualisation, SaaS, Cloud Computing…), puis par ses valeurs (Collaboratif, Agilité, Lean…).

La gestion de projet traditionnelle doit elle-aussi s’adapter et passer à l’ère du 2.0, qui se définit par : la simplicité, la légèreté et une plus large collaboration sur fond de technologies.

Il s’agit d’une transformation majeure de la gestion de projet. L’approche traditionnelle de la gestion de projet, fondée sur les processus, le contrôle et la planification rigoureuse, convient de moins en moins à notre époque moderne, à un environnement changeant, aux besoins en retours sur investissement rapides et à la mentalité des équipes.

Cette transformation a déjà été initiée depuis plus de 10 ans par la vague de l’Agilité et du Lean. Aujourd’hui, ces approches sont reconnues par les organisations professionnelles. Ainsi le P.M.I., auteur du fameux référentiel de gestion traditionnelle de projet PMBoK, propose désormais une certification Agile. La transformation de la gestion de projet est donc solidement engagée.

Pour les entreprises, cette transformation est le moyen de gagner en compétitivité en améliorant la performance des équipes grâce à une collaboration plus efficace, fondée sur la confiance et la responsabilisation. Voici une analogie avec la transformation du Web vers le 2.0 qui a eu lieu sur Internet dans les années 2000.

Continuer la lecture de « Gestion de projet 2.0 »

Initiation à la Valeur Acquise (Earned Value)

En gestion de projet, la technique standard de suivi de projet s’appelle la Valeur Acquise. Sa principale mission est la mesure des écarts par rapport au plan, et donc la maîtrise du projet. Cette technique fait partie intégrante des référentiels méthodologiques (PMBoK, IPMA…). En anglais, son nom est Earned Value Management (EVM).

Objectif de la Valeur Acquise: Maîtriser les écarts de coût et de délai

Une bonne gestion de projet passe nécessairement par la maîtrise des écarts.

Voyons ensemble comment le diagramme de la Valeur Acquise nous permet de visualiser facilement les écarts.

Valeur Acquise - courbe en S

Capture d’écran de TimePerformance, le logiciel de gestion de projets par la valeur acquise.

Sur ce diagramme, on y trouve 3 courbes.

  • La courbe bleue représente le plan.
  • La courbe verte représente l’avancement réel.
  • La courbe rouge représente le coût réel (hors la partie en pointillés).

Les positions relatives des courbes montrent les écarts de coût et de délai du projet.

La courbe verte est au-dessus de la courbe bleue. Donc l’avancement est supérieur au plan. Le projet est donc en avance (écart de délai).

La courbe rouge est au-dessus de la courbe verte. Donc le coût réel est supérieur à l’avancement réel. Le projet est donc en surcoût (écart de coût).

Remarque: Le diagramme de la valeur acquise est aussi connu sous le nom de Courbe en S pour sa forme caractéristique.

Qu’est-ce que la Valeur Acquise ?

La valeur acquise, c’est la courbe verte, c.-à-d. l’avancement réel du projet. On appelle «valeur acquise» l’avancement réel quand il est valorisé en euros. L’intérêt de valoriser l’avancement en euros est de pouvoir comparer sa valeur par rapport au budget (le plan) et au coût réel.

Le principe de la Valeur Acquise, c’est simplement de donner une valeur en euros à l’avancement réel pour le comparer à un budget et à un coût réel.

A partir des 3 valeurs, valeur acquise, budget à date et le coût réel, la technique de la valeur acquise fournit des formules simples pour calculer des écarts et des indices de performances.

Le + de la Valeur Acquise: la prédiction à terme

Le fait d’avoir calculé les écarts sur le projet permet de faire des prédictions par extrapolation. Dans la technique de la valeur acquise, on s’intéresse à prédire le point d’atterrissage du projet, ce qu’on appelle l’estimé à terme.

Dans le diagramme ci-dessus, la prévision est représentée par la partie en pointillés de la courbe rouge.

La technique de la valeur acquise prédit dans l’exemple que le projet se terminera 3 semaines en avance avec un surcoût de 10%.

Comment calculer la Valeur Acquise ? Comment valoriser un avancement ?

Le principe du calcul est simple: chaque élément du projet a un poids qui correspond à son montant dans le budget. Ainsi, à chaque fois qu’une tâche est terminée ou qu’un livrable est achevé, le montant du budget prévu pour cette tâche ou ce livrable s’ajoute à la valeur acquise du projet.

Malgré sa simplicité – ou plutôt grâce à sa simplicité – cette technique est très efficace et facile à utiliser. Elle fournit des informations essentielles au pilotage.

Le seul réel obstacle à la démocratisation de la valeur acquise est la lourdeur des calculs. Ils sont fastidieux du fait de la volumétrie des données et de la nécessité d’historiser les valeurs. De plus, la prise en compte des changements en cours de projet constitue un réel challenge pour la mise à jour des courbes. Sans outillage suffisant, la mise en œuvre de la valeur acquise devient rapidement un casse-tête pour le chef de projet.

Sur ce dernier point, nous vous invitons à essayer gratuitement notre logiciel de gestion de projets, qui est la solution la plus simple et la plus facile pour bénéficier de la technique de la valeur acquise.

Perles de PMO

Un peu d’humour pour la rentrée…

Voici quelques perles de vrais PMO glânés au cours des rencontres, qui nous ont laissés sans voix.

Nous: «Il y a plein de livrables et d’étapes dans TimePerformance dont l’avancement est à 100%. Il faudrait les clore, non ?»

PMO: «Ben, l’avancement est à 100% mais ce n’est pas vraiment terminé. Il y a quelques retouches à faire ici et là…»

Le même pour le même projet…

La prédiction dans le diagramme de la valeur acquise dans TimePerformance montre clairement que le projet qui devait finir en octobre ne finira pas avant avril-mai de l’année suivante. (ce qui s’est démontré vrai par la suite)

PMO: «On le sait tous à la DSI mais il ne faut surtout pas le dire.»

Un autre.

 PMO: «Nous sommes un centre de coûts….. Donc on ne gère pas les coûts.»