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 »

Le Malentendu à propos des Valeurs Agiles

Souvent il est question des 4 valeurs agiles quand on cite le Manifeste Agile. Ce mot « valeur » est dangereux pour le mouvement agile.

« Valeur » – un mot maladroit

L’entreprise a ses valeurs. Les individus ont leurs valeurs. En positionnant l’Agilité sur le plan des valeurs, on déclare la guerre aux valeurs existantes. (Bon courage 😉 )

Dire que l’Agilité repose sur des valeurs génère automatiquement des résistances lors de sa mise en oeuvre.

Mais l’objectif de l’Agilité n’est pas de révolutionner la culture des entreprises, ni de changer les gens.

Le Manifeste Agile commence par « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. ». On est loin du plan des valeurs et il sera facile de mettre tout le monde d’accord sur cet objectif…

Un problème de traduction

Dans la traduction officielle du manifeste, on utilise le verbe valoriser et non le mot valeur.

Ces expériences nous ont amenés à valoriser :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

source: http://agilemanifesto.org/iso/fr/manifesto.html

On pourrait dire aussi donner plus d’importance à ceci plutôt que cela. Ce n’est pas une question de valeurs. C’est un choix de priorités.

« Préceptes Agiles »

Plutôt que de parler de « valeurs agiles », il vaut mieux dire les 4 préceptes agiles, c.-à-d. des « recommandations pratiques enseignées par l’expérience » (cf. Larousse).

En effet, pour tous les « anciens développeurs » qui ont connu les méthodes et les processus lourds des années 90, le chef de projet qui fait un Gantt qui sert à rien, les spécifications incompréhensibles et obsolètes, les 4 pseudo-valeurs sont exactement ça: des recommandations pratiques issues des erreurs passées, ce qu’on appelle l’expérience à en croire Oscar Wilde.

Ces préceptes sont déjà une révolution. Ils s’opposent à la croyance héritée du Taylorisme profondément ancrée dans le monde de l’entreprise: les méthodes et les processus sont la clé de l’efficacité et de la réussite.

Il y a suffisamment à faire sur le plan des croyances pour ne pas entrer sur celui des valeurs.

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.

Équipe pluridisciplinaire SCRUM: avantages et inconvénients

La méthode Scrum a introduit le concept d’équipe pluridisciplinaire (cross-functional team).

Une équipe pluridisciplinaire Scrum est une équipe pluridisciplinaire dont les membres sont eux-mêmes pluridisciplinaires.

L’avantage évident est de faciliter la collaboration inter-discipline. Mais cela ne serait pas suffisant pour justifier la contrainte supplémentaire de devoir trouver les « bons profils ».

Quel est l’avantage d’une telle équipe par rapport à une équipe pluridisciplinaire classique où chaque membre à un rôle précis ?

L’avantage souvent méconnu est de pouvoir affecter les personnes à 100% sur un projet.

Continuer la lecture de « Équipe pluridisciplinaire SCRUM: avantages et inconvénients »

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 ?