Gouvernance projet, une cause profonde d’échec

par | Décider, Intelligence collective, Leadership, Projet

Combien de fois rate-t-on les objectifs d’un projet par défaut de gouvernance projet ?

Comment la question de la mise en place d’un comité de pilotage doit-elle être adressée ?

Pourquoi structurer une gouvernance projet solide et efficace est-elle la mission première du chef de projet (oui j’insiste du chef de projet) ?

Quelle est la responsabilité du chef de projet pour transformer cette gouvernance en un outil d’arbitrage face à la complexité ?

Dans cet article, je partage une expérience, vécue dans une startup, où l’absence de gouvernance projet structurée conduisait vers une possible catastrophe, et les leçons à en tirer pour infléchir l’orientation de la courbe d’un projet mal enclenché.


Selon Harvard Business review, l’heure de la « project economy » a sonné. Je ne sais pas comment ils le calculent, mais la part des « projets » dans l’économie allemande dépasserait les 40% du PIB. Ce chiffre donnerait-il envie de les réussir, ces fameux projets ?

 

Or, que se passe-t-il souvent, dans la multitude des projets en entreprise. Un sujet transversal est à traiter. On (c’est qui « on ») nomme un chef de projet, souvent quelqu’un de technique pour résoudre la combinaison complexe. L’heureux élu se voit prendre la charge :

    • d’un objectif plus ou moins clair
    • d’une responsabilité de réussite
    • d’une équipe plus ou moins dédiée, plus ou moins transversale, plus ou moins multi-taches
    • d’une date limite à respecter
    • éventuellement d’un budget

 

La consigne est souvent celle-ci : démerde toi.

 

Pour les plus chanceux, une formation est proposée. Avec la chanson des méthodes agiles, un développement itératif est lancé, pour coller au besoin du client. Roulez jeunesse.

 

J’observais un jour, dans une start-up (1) où je suis intervenu, le « body language » (2) des participants à un daily scrum (3) pour atteindre le résultat intermédiaire du sprint (4) en cours. Z’avez compris ?

  1. Startup = entreprise en création et progression supposée être rapide et glorieuse
  2. Body language = tout ce qui passe en message non verbal dans l’attitude, que les sens captent très bien, mais dont la substance est rarement analysée et utilisée dans la communication des gens centrés sur la technique
  3. Daily scrum = la réunion quotidienne qu’anime le « scrum master » (5) pour s’assurer que les développeurs (on est ici en informatique) avancent conformément aux demandes, comprennent les prochaines attentes
  4. Sprint = un fondamental de la méthode Agile qui consiste à littéralement courir, en général une à deux semaines, vers un livrable (6) intermédiaire du projet
  5. Scrum master = celui qui anime les réunions scrum (la mélée du rugby), souvent quotidiennes, avec l’équipe technique
  6. Livrable = un morceau du produit que l’on livre au client, une partie qui ne constitue pas le tout 

Ouf, en voici terminé avec quelques définitions de mots anglais de la littérature projet.

 

body language

Je reprends : en observant le fameux « body language » de l’autre coté de la cloison vitrée, je me disais « ils ont tous l’air de s’ennuyer à mourir ». Le fameux scrum master parlait. Le peuple des développeurs semblait roupiller. Le projet allait mal.

 

Quand j’investiguais plus avant, je réalisai que :

  • Le chef de projet avait un profil technique, plutôt discret, plein de bonne volonté et débordé. Il détenait tellement de ficelles du projet que son rôle était hyper critique. Sans lui (maladie ou démission), le projet était vraiment à risque.
  • Les outils d’échange avec le client étaient archaïques : un fichier excel traversait chaque jour les océans pour rendre compte de l’avancement du projet… des incohérences et incompréhensions faisaient le lit d’échanges courriels aussi interminables qu’inefficaces, de disputes et de suspicions nocives.
  • Aucune priorité n’était clairement établie, aucun tableau de bord ne permettait ne comprendre la direction que prenaient les développements, ni le statut de résolution des inévitables défauts.
  • Il n’existait aucun organe de pilotage du projet, la gouvernance projet était inexistante, le CEO en était à dire qu’il devrait bientôt signer des engagements pour le client avec son sang (SIC).
  • Accessoirement, ce projet représentait 80% du chiffre d’affaires de cette jeune pousse technologique.

 

La priorité était d’établir une véritable gouvernance projet
en intelligence avec le client

 

Autrement dit :

  • Déterminer de chaque coté (chez le client comme au sein de la startup) la personne de pouvoir qui s’investirait dans le rôle l’arbitre suprême.
  • Convenir de qui allait participer régulièrement à un comité de pilotage interne, et un autre conjoint avec le client.
  • Réserver immédiatement des dates prévisionnelles sur 3 mois glissants dans l’agenda, pour les réunions de pilotage internes et conjointes.
  • Distribuer les taches du chef de projet dans les bonnes mains.
  • Choisir des outils appropriés et communs avec le client pour partager les bonnes informations, créer un référentiel de travail.
  • Identifier chez le client et dans la startup qui parlait à qui et quand, pour éviter que tout converge vers une seule personne.
  • Définir des tableaux de bord simples à comprendre (même pour les grands chefs à plume), pour jauger en un clin d’oeil de l’évolution du projet, et éviter de s’étriper pour des broutilles.

 

Quelques semaines plus tard, après plusieurs réunions de pilotage, des outils et des responsabilités clarifiées, le projet voguait dans des eaux plus tranquilles.

J’avais pris la place d’animation de la gouvernance projet. L’animation, ce n’est pas la décision : c’est porter aux décideurs les éléments factuels et précis qui leur permettent de faire les bons arbitrages.

 

Je me souviens avoir démarré une réunion de pilotage à Montréal, une autre à Sydney, par un rappel du rôle de la gouvernance : 

« Nous sommes ici, vous êtes dans cette salle pour traiter des sujets sensibles, difficiles, pour prendre les décisions qu’attendent les personnes de terrain. Nous ne sortons pas de la salle tant que tous les points rouges (critiques) de mon tableau de bord ne sont pas traités. Si nous avons le temps, nous aborderons les points oranges (difficiles). Enfin, les points jaunes et verts seront évoqués si nous en avons le loisir ».

(sous-entendu, cette réunion coûte très cher, prière de faire le boulot)

 

Je présentais des diapos peu nombreuses, visuelles, chiffrées, factuelles, avec un code couleur évident à comprendre. L’objectif : faciliter la compréhension des grands chefs à plumes qui ont peu de temps pour analyser, et pour lesquels le travail de clarification des enjeux facilite l’exercice de leur pouvoir.

 

Pour que la gouvernance projet soit efficace, il convient à la fois de la mettre en place, et de la faire vivre. La gouvernance projet facilite le travail des équipes projet puisqu’elle nettoie les grandes orientations. En sortant de le réunion de comité de pilotage, le chef de projet peut claironner : « cette décision a été prise au top, nous pouvons avancer ».

 

Pourquoi la gouvernance projet
est-elle souvent une cause profonde d’échec ? 

 

absence de gouvernance1 – Parce qu’elle n’existe pas vraiment. Le chef de projet ne crée pas la structure, car il estime que ce n’est pas à lui de le faire. Or c’est une exigence à poser quand on prend le poste de direction d’un projet. Les chefs à plumes sont occupés à autre chose. Le chef de projet doit fermement être à l’initiative de création de la gouvernance.

2 – Parce que le chef de projet ne fait pas toujours le travail de décrypter et de présenter de manière intelligible les priorités sur lesquelles les grands chefs à plumes doivent décider. Il est toujours facile de se camoufler derrière des piles de rapports, de tableaux de chiffres ou de diaporamas à n’en plus finir. Préparer la synthèse est une mission cruciale pour que les bonnes décisions soient prises.

3 – Parce que les grands chefs à plumes imaginent parfois qu’il suffit de lancer le projet avec un responsable intelligent, technique souvent, pour que tous les enjeux (techniques, planning, risques, ressources, alliés et adversaires, outils, budgets, relation client) se règlent magiquement, en participant de ci de là à des revues de projet incompréhensibles.

4 – Parce que la mode des méthodes Agile fait croire qu’il est possible de s’affranchir des discussions difficiles, à mener au bon endroit.

5 – Parce que les grands chefs à plumes pensent parfois, en leur for intérieur, que le chef de projet pourra toujours servir de fusible, s’ils n’ont pas eux-mêmes mouillés la chemise.

 

La gouvernance projet, c’est oser mettre sur la table des décideurs la complexité. Ce sont des méthodes, enrichies de l’intelligence collective, pour que les beaux cerveaux se penchent, avec des données de qualité, sur la résolution, sur la recherche de solution.

complexité

Pourquoi le sujet de la gouvernance projet est-il mal compris ?

 

Peut-être parce que, ici comme ailleurs, c’est affaire de marier concept et mise en oeuvre, prise de hauteur et pragmatisme, méthode et bon sens, egos au placard et diplomatie de convergence…

 

Atelier gouvernance projet

 

0 commentaires

Soumettre un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Ces sujets peuvent également vous intéresser

Bonjour, bienvenue sur mon blog

Je m’appelle Laurent de Rauglaudre (je sais, mon nom est imprononçable). Sur ce blog, j’écris des articles sur le leadership, le métier de consultant libre et de coach.

Je batifole à partir de mes expériences, mes lectures, mes succès et mes fausses pistes. Je suis motivé par le leadership responsable.

J’espère que vous trouverez matière à inspiration.

Bonne lecture,

Laurent

Prochains Évènements