Catégorie : Gestion de Projet & Agilité

Articles de conseil et de retour d’expérience sur la gestion de projet et les méthodes Agiles.

Modèle de plan pour Prince2

Chez Time Performance, nous sommes fans de la méthode de gestion de projet Prince2 pour les raisons suivantes.

Prince2 fournit une vraie méthode de gestion de projet avec un cycle de vie de projet standard, une organisation et des rôles précis. Cette méthode guide les chefs de projet, tandis que les référentiels de bonnes pratiques généralistes comme le PMBoK propose une liste d’outils et de techniques. Prince2 permet de mettre immédiatement la gestion de projet sur des rails, ce qui est un point commun avec notre logiciel de gestion de projets TimePerformance.

Prince2 a été conçu pour l’approche itérative et incrémentale, qui est la bonne approche pour le développement logiciel, notre métier.

Prince2 repose sur le principe du management par exception. Ce principe donne beaucoup plus d’autonomie aux équipes tout en gardant le contrôle du projet. Ce principe est dans l’ADN de notre solution TimePerformance.

Prince2 propose une planification orientée produit (product-based). Pour comparaison, l’approche classique repose sur une planification orientée tâche (cf. Gantt, PERT). La planification orientée produit est beaucoup plus simple et focalisée sur l’essentiel: les livrables. TimePerformance utilise ce type de planification avec un gain de temps important pour les chefs de projet.

Prince2 est le complément idéal des méthodes agiles Scrum et XP. Les méthodes agiles, centrées sur l’équipe de développement, ne couvrent pas certains domaines essentiels de la gestion de projet.

Modèle de Projet Prince2

Voici un modèle de projet Prince2 construit avec le logiciel TimePerformance.

Version complète en PDF du modèle Projet Prince2

Voici le Gantt avec le phasage d’un projet selon Prince2. Les étapes d’avant-projet et de clôture avec leurs livrables de gestion de projet sont standardisées par la méthode. Les étapes de construction sont à définir avec le contenu spécifique du projet.

PRINCE2® is a Registered Trade Mark of AXELOS Limited

La méthode agile SCRUM et le logiciel TimePerformance

Le logiciel de gestion de projet TimePerformance a été conçu pour apporter aux équipes SCRUM  une solution simple de gestion de projet qui respecte les principes de l’Agilité et apporte le top de la gestion traditionnelle pour le management.

Petit rappel sur la méthode SCRUM

analogie de la mêlée de rugby avec la méthode agile Scrum

SCRUM est une Méthode Agile créée en 1996 par Ken Schwaber et Jeff Sutherland, conçue initialement pour le développement logiciel.

La principale motivation de son élaboration est de pouvoir gérer des projets complexes avec de nombreuses inconnues, pour lesquels les méthodes classiques (cycle en V, cascade etc.) sont par nature inadaptées.

Pour gérer ce type de projet, il faut pouvoir s’adapter facilement et rapidement aux changements fréquents. C’est le concept d’Agilité.

L’image de la mêlée de Rugby (SCRUM en anglais) illustre parfaitement le style de cette méthode: progression continue, effort soutenu, importance de la cohésion de l’équipe, faire face ensemble pour surmonter les difficultés…

Management Visuel vs Utilisation d’un Logiciel

Le management visuel avec des post-it sur le mur a des avantages indéniables, notamment de convivialité. Mais il a aussi de nombreux inconvénients.

Garder la cohérence entre les post-it, les backlogs dans Excel et les courbes d’indicateurs est fastidieux.

De plus, un tableau vissé au mur n’est pas très pratique pour les communications vers l’extérieur ou les équipes réparties sur plusieurs sites.

L’utilisation d’un logiciel unique permet aussi l’automatisation de certaines tâches administratives.

La question n’est pas de remplacer le management visuel par un logiciel. Il s’agit de remplacer un ensemble hétéroclite de petits outils ou feuilles de calcul annexes, par un logiciel unique et simple.

Rationalisation de l’outillage, génération en temps réel des indicateurs et des courbes, partage de l’information font partie des bénéfices de l’utilisation de TimePerformance.

SCRUM et le monde de l’Entreprise

Convertir toute l’entreprise à la terminologie Scrum est difficile. Il y a très peu de chance que les story points, le burndown, les backlogs, la vélocité etc. soient un langage compréhensible par tous.

Par ailleurs, le contexte d’une entreprise ajoute des contraintes au niveau de la gestion des projets: suivi budgétaire, contrôle des coûts, suivi des temps… Le reporting de projet requiert de parler en jours-hommes et en euros, notamment pour le service Compta.

La spécificité de TimePerformance est de faire le pont entre agilité et management traditionnel.

Cette capacité est illustrée par les nombreuses vues tantôt agiles tantôt classiques proposées par le logiciel.

Cockpit de projet

Vu de l’équipe, le projet suit la méthode Scrum avec ses outils spécifiques: tableau des tâches, release backlog… Vu de l’extérieur, le projet Scrum est géré « comme les autres » avec un suivi budgétaire, un planning…

En fait, pour le management, le projet Scrum géré avec TimePerformance sera bien mieux géré que les autres projets. En effet, TimePerformance met en oeuvre la technique de la valeur acquise. Cette technique est recommandée par les référentiels professionnels de gestion de projet pour la gestion financière et le calcul de l’avancement.

C’est donc le top de la gestion de projet traditionnelle qui est mis à disposition des équipes agiles. De quoi crédibiliser Scrum auprès du management !

Autres bénéfices

Voici quelques autres apports possibles de TimePerformance pour les équipes.

  1. Intégration avec la gestion des ressources
  2. Historique du projet et possibilité d’analyser ce qui s’est réellement passé.
  3. Mesurer les évolutions de périmètre du projet.
  4. Améliorer les estimations grâce à la mesure des écarts planifié vs réalisé au niveau de chaque user story.
  5. Renforcer la Definition Of Done grâce à la fonctionnalité « Méthode ».

Pour la mise en oeuvre pratique de SCRUM avec TimePerformance, lire l’article Guide pour utiliser TimePerformance avec la méthode agile SCRUM.

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 »