Définition de la gestion de projet pour une mise en oeuvre pragmatique

En matière de gestion de projet, il y a un énorme fossé entre la théorie et la pratique. Les méthodes et les référentiels sont trop compliqués pour être mis en oeuvre. En pratique, moins de 10% des activités préconisées par ces méthodes sont utilisées.

Cet article est un retour à des choses simples: une définition concise et un framework simple pour une mise en oeuvre pragmatique de la gestion de projet.

Définition

Dans un projet, le plus important est de construire le produit. Néanmoins construire le produit n’est pas suffisant car les choses ne se font pas d’elles-mêmes.

Il est nécessaire de mettre en place de la coordination entre les acteurs du projet, un suivi de l’avancement, une gestion financière… c’est-à-dire une gestion de projet.

La gestion de projet est la discipline qui regroupe l’ensemble des activités « d’organisation » du projet qui s’ajoutent aux activités de « construction » du projet.

Remarque: il ne suffit pas de nommer un chef de projet pour avoir une gestion de projet. La gestion de projet doit produire des livrables (ex: rapport d’avancement, tableau de bord de gestion…). Elle doit inclure certaines activités basiques de gestion (ex: suivi des coûts, des délais…). Une « gestion de projet de tête » n’est pas une gestion de projet.

Les activités de gestion de projet sont nombreuses car organiser consiste à se préoccuper de tout.

Les activités de gestion de projet sont simples. La gestion d’un projet n’est pas la gestion d’une entreprise.

C’est le fait de penser à tout qui est compliqué. C’est pourquoi la gestion de projet demande méthode, discipline et un outil adapté.

Continuer la lecture de « Définition de la gestion de projet pour une mise en oeuvre pragmatique »

Structure du plan d’un projet

Dans TimePerformance, tous les projets ont un plan avec une structure standardisée reposant sur 3 concepts de base: les phases, les livrables et les tâches.

Il est important de bien comprendre cette structure. Cela facilite l’utilisation du logiciel. Mais surtout, cela aide à la planification et à la gestion de projet. En effet, cette structure est du simple bon sens et on la retrouve dans toutes les méthodes de gestion de projet (Scrum, Prince2, Cycle en V…).

Plan Projet à 3 niveaux

Les niveaux du plan d’un projet sont:

  • Niveau 1: Phasage
  • Niveau 2: Livrables
  • Niveau 3: Tâches

Cette structure à 3 niveaux est visible dans la feuille de route du projet comme dans l’exemple ci-dessous.

Le plan de ce projet prévoit qu’il se déroulera en 4 phases: Initialisation, Maquettage etc.. (niveau 1). Pendant la phase de « Maquettage », il y a 4 livrables à produire: Choix du CMS, Maquette du site… (niveau 2). Pour réaliser le livrable « Maquette du site », il y a 8 tâches à faire : réalisation de la Page référence client… (niveau 3).

La structure du plan d’un projet dans TP est donc la suivante:
Projet → Phasage → Livrables → Tâches

Voici le même plan sous forme d’un Gantt. Note: les tâches ne sont pas visibles.

Concepts

Les Phases et les Étapes

Un phasage de projet est indispensable dès que la durée d’un projet dépasse quelques semaines. Le phasage garantit la maîtrise de l’avancement et des délais grâce à la mise en place de jalons.

Continuer la lecture de « Structure du plan d’un projet »

Les différents types d’avancement

problemEn théorie, il est possible de définir plein de sortes d’avancement:

  • l’avancement physique
  • l’avancement en charge
  • l’avancement en coût
  • l’avancement en délai

En pratique, on saisit des avancements physiques (%) ou en charge (reste à faire) au niveau élémentaire du projet (tâches…).
L’outil de gestion de projet en déduit les avancements en coût et en délai du projet selon la technique de la valeur acquise.

Agilité: de l’auto-organisation vers l’auto-gestion

coaching PMA et gestion de projet 2.0La méthode Scrum et l’Agilité sont en train de bouleverser la culture des entreprises avec le principe de self-organizing team: une équipe auto-organisée qui n’a plus de manager et qui gère seule ses tâches. La justification d’une équipe auto-organisée est simple: responsabiliser et donner plus d’autonomie aux équipes.

Pour être tout à fait autonome, pourquoi une équipe projet ne gérerait-elle pas aussi son budget ? Une sorte d’auto-gestion…

Coûts, budget, ROI et rentabilité sont des termes absents des méthodes Agiles. De tous les leviers qui influencent les décisions dans une entreprise, l’aspect financier est sans doute le plus puissant. Il a le pouvoir de vie et de mort sur les projets. L’ignorer, c’est prendre un risque.

La proposition est d’intégrer la gestion des coûts et du budget dans le fonctionnement des équipes agiles. 

Concrètement, en quoi consisterait l’autogestion ?

Pour les équipes auto-organisées, cela consiste simplement à ajouter 2 ou 3 indicateurs financiers à leur « radiateur d’information » et à utiliser ces informations dans leur communication externe et pour la prise de certaines décisions.

Par exemple, avec l’autogestion, le backlog produit Scrum montre une liste de fonctionnalités avec un budget associé – Fonctionnalité X 11500€, Fonctionnalité Y 23200€… – comme pour les options d’une voiture neuve. C’est beaucoup plus concret pour le Product Owner et les utilisateurs que les estimations en Story Points qui sont artificiels et relatifs à cette équipe.

Autre illustration: en mode autogestion, l’équipe sait justifier financièrement auprès du management certains choix :

  • investissement pour gagner en productivité (équipement, logiciel…),
  • choix de faire un développement interne ou l’achat d’un composant sur étagère,
  • appel à un prestataire, à la sous-traitance pour des compétences spécifiques
  • recrutement

Avec un logiciel comme TimePerformance, la gestion financière d’un projet se fait toute seule.

Les bénéfices business

  1. Faire coïncider les enjeux réels de l’entreprise avec ceux des équipes projet, aligner les objectifs du management et des équipes
  2. Sensibiliser les équipes à l’importance de la maîtrise budgétaire et de la rentabilité (notamment pour sociétés de service)
  3. Accélérer les prises de décisions d’investissement pour gagner en productivité
  4. Intégrer les impacts financiers dans les choix techniques

Les obstacles: le management et le tabou de l’argent

Cela ne sera pas facile de faire admettre aux managers qu’ils doivent déléguer une partie de leurs prérogatives, la gestion des coûts et des budgets. Comme nous l’avons dit, l’aspect financier en entreprise est le vrai pouvoir.

Mais un manager intelligent verra dans cette délégation une opportunité pour se défaire de tâches administratives de gestion financière pour se tourner vers des missions à plus forte valeur ajoutée: le pilotage, la recherche d’opportunités, le développement de la vision, l’amélioration de la relation client, la conduite du changement, l’amélioration des processus…

Comment surmonter les obstacles

C’est très simple: faîtes-le. C’est à dire gérez les coûts et le budget même si on ne vous le demande pas. Cela ne demande aucun effort avec un logiciel comme TimePerformance. Et il n’est pas besoin d’avoir des chiffres exacts, car ce qui compte est l’ordre de grandeur.

Puis glissez subrepticement au hasard des conversations ou des réunions quelques indicateurs montrant que vous maîtrisez les aspects financiers du projet. Et peut-être que petit à petit on vous fera confiance et on vous confiera plus de responsabilité.

Sachez enfin que cette délégation de la gestion du budget et des coûts n’a rien d’exceptionnel. En fait, elle est pratiquée partout ailleurs que dans l’Informatique. Un chef de produit Marketing a un budget. Un chef de chantier dans le BTP gère un budget et des coûts. Dans le PMBoK, la gestion financière du projet est indissociable de la gestion de projet.

Il y a fort à parier que si les équipes agiles se mettent à parler budget et rentabilité de leurs projets dans les réunions, l’Agilité ne risquera plus de passer pour un « truc » de développeur auprès du management.

Bien utiliser le diagramme de Gantt

Chaplin Modern Times
A l’origine, le diagramme de Gantt est un outil d’organisation scientifique du travail inventé au début du 20ème siècle pour améliorer la productivité des chaînes de montage dans les usines.

Quelques décennies plus tard, le Gantt a été utilisé avec succès pour gérer de grands projets d’infrastructure avant de devenir une icône de la gestion de projet. C’est aujourd’hui un outil incontournable du chef de projet. Et pourtant, il convient de l’utiliser avec discernement…

Si tous les projets ont un besoin de planification et de respect des délais, ils ne s’apparentent pas tous à du travail à la chaîne, ni à des grands projets de construction.

Dans le développement informatique, combien de diagrammes de Gantt finissent sans suite ? Environ 99%…

Le piège est de faire un Gantt par habitude sans se poser la question de l’utilité de ce qui n’est au final qu’une technique parmi d’autres. A quoi sert  le Gantt ? Quels problèmes résout-il ? Y a-t-il des conditions à son utilisation ?

Diagramme de Gantt et Planification

Diagramme de Gantt

Le Gantt permet de visualiser simplement les délais, l’ensemble des tâches et leur séquencement.

Mais c’est une erreur de commencer la planification du projet dans un Gantt. 

En effet, dans le Gantt, il y a tout: la définition du périmètre du projet, la décomposition en tâches et leur ordonnancement, l’estimation des charges et le calcul des durées, les affectations, la disponibilité des ressources… C’est trop d’un coup. La planification d’un projet requiert un processus d’analyse qu’il est dangereux de court-circuité…

La construction du Gantt est la dernière étape du processus de planification. Il permet de calculer les délais et d’optimiser les ressources.

Le Gantt peut être utilisé à un niveau macroscopique pour visualiser le projet et les délais. Mais pour cela, il existe d’autres outils plus simples de visualisation comme la ligne de temps.

Dans la suite de l’article, on considère uniquement le cas de l’utilisation du Gantt pour une planification détaillée jusqu’aux tâches des équipes.

Un outil indispensable pour…

Le Gantt est nécessaire pour gérer le séquencement des tâches lorsque les interdépendances sont fortes. Sur un chantier de construction, ces interdépendances sont très nombreuses et incontournables. (Il faut couler les fondations avant de pouvoir monter les murs…) Un outil pour les gérer est indispensable.

Le Gantt est aussi nécessaire lorsque les intervenants sur le projet sont nombreux. Il permet de construire les calendriers d’intervention, de répartir les tâches et de coordonner les équipes.

Sur un chantier de construction, il y a plusieurs équipes (terrassiers, électriciens, plombiers..) qui n’interviennent qu’à des moments précis, se croisent et donc communiquent peu entre elles; d’où l’importance d’une planification précise.

Mais un outil complexe

Pour un projet de taille moyenne avec une équipe de 6 personnes sur 1 an, on atteint très vite le millier de tâches à ordonnancer et à gérer. Même avec un bon logiciel, c’est un travail fastidieux.

Planifier avec un Gantt nécessite un effort important de la part du chef de projet. Il peut même être nécessaire de déléguer la planification à un expert.

Mais les enjeux du chapitre précédent peuvent justifier ce travail important de planification.

Quand ne pas utiliser le Gantt…

Le Gantt est utile pour planifier dans le détail. Or construire un planning détaillé et calculer des délais n’ont de sens que si:

  • l’ensemble du contenu du projet est connu à l’avance
  • les estimations sont relativement fiables

Dans certains projets, le périmètre flou, les inconnues et les aléas rendent toute velléité de planifier dans le détail futile.

Notamment, dans le domaine du développement informatique, les projets avec ces caractéristiques sont le cas général. Ceci est à l’origine du mouvement Agile et de son énorme succès. Gérer un projet Agile avec un Gantt est donc une hérésie.

Dans certains domaines, les problèmes adressés par le Gantt, séquencement des tâches et gestion complexe d’équipes, sont mineurs.

Toujours dans le développement logiciel, il n’y a pas de problème de séquencement des tâches car il y a peu de contraintes fortes dans l’ordre pour faire les choses. Il n’y a pas non plus de gros problème de gestion des équipes (solution simple de gestion des ressources).

Dans ces contextes, l’utilisation du Gantt génère un travail important avec des replanifications perpétuelles et ne résout aucun des problèmes majeurs.  Ceci explique l’abandon rapide du Gantt observé si souvent.

Exemples concrets

Voici 2 projets « informatiques » avec des enjeux très différents, donc un besoin d’outil différent.

Type de Projet Déménagement de salle serveurs Développement d’un logiciel
Problématique Réduire la durée de coupure de service (optimisation des délais) Répondre aux besoins des utilisateurs, intégration aux SI, ergonomie, apporter de la valeur… Problématiques variées où les délais sont une variable parmi d’autres.
Contenu du projet Parfaitement connu (équipement actuel) Cahier des charges ou spécifications qui vont évoluer, solution à peine ébauchée…
Estimation de la charge de travail Facile, déjà fait Marge d’erreur importante du fait de la nouveauté et des inconnues, nécessite d’acquérir plus de connaissances sur le problème et d’expérience dans les technologies ou le fonctionnel
Ordonnancement des tâches Important, nombreuses règles à respecter dans le montage ou le démontage des équipements. Pas important. Grande flexibilité.
Coordination des équipes Au moins 2 équipes distinctes très spécialisées (déménageurs et administrateurs réseaux) qui doivent se coordonner avec des délais courts Une seule équipeImpossible de prédire en détail le travail à faire du fait des nombreuses inconnues du projet.
Conclusion Utilisation du Gantt recommandée Se focaliser sur le périmètre du projet, l’architecture, les technologies, l’ergonomie, les risques… plutôt que sur le séquencement des tâches dans un Gantt.

Conclusion

Le contexte idéal pour l’utilisation du Gantt se définit par:

  • Le contenu du projet est défini avec un grand niveau de détail
  • Les charges de travail peuvent être estimées avec une bonne précision
  • Les dépendances entre les tâches sont des contraintes fortes
  • La coordination et la gestion des équipes sont complexes

Le diagramme de Gantt est un puissant outil d’optimisation du travail plutôt réservé à des experts de la planification.

Mais diagramme de Gantt et gestion de projet ne sont pas synonymes. S’il n’y a pas les conditions pour utiliser le Gantt, ni de valeur à le faire, il vaut mieux s’en passer.

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 ?

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