Aujourd’hui, troisième épisode des principes directement applicables par les chefs de projet.

Principe #3 : « Demandez pourquoi les choses sont faites. »

Dit autrement : si vous ne connaissez pas le “pourquoi”, votre “comment” est probablement faux.

Je vous donne une scène classique. On vous demande une fonctionnalité, un rapport, un tableau, un processus… et tout le monde est très pressé. Vous pouvez livrer ça vite, proprement, dans les délais. Et puis, le jour de la démo, quelqu’un dit : « Oui mais… ce n’est pas ça dont on avait besoin. »

Ce n’est pas un problème de compétence. C’est un problème de question.

Ma version “bon sens” du principe : avant de construire, vérifiez l’intention.

Trois questions simples, qui évitent de fabriquer du baratin industriel :

1. Pourquoi on le fait ? Quel problème on résout, pour qui ?

2. Qu’est-ce qui se passe si on ne le fait pas ? (ça révèle la vraie priorité)

3. Comment saura-t-on que le problème est résolu ? (un résultat observable)

Et si vous voulez une technique encore plus simple : le “pourquoi” en cascade. Vous demandez “pourquoi ?” une deuxième fois… puis une troisième. En trois “pourquoi”, vous passez souvent d’une solution imposée… à un vrai besoin.

Et c’est là que Project Cockpit devient pratique. Parce que chaque demande, chaque décision, chaque changement est relié à une justification et à de la valeur. Quand quelqu’un arrive avec « il faut absolument ajouter ça », vous ne discutez pas seulement de charge. Vous demandez : quel besoin, quel bénéfice, quel critère de succès ?

Conclusion : un chef de projet n’est pas un exécutant de demandes. C’est un traducteur d’intentions. Quand le “why” est clair, le “how” devient évident. Quand le “why” est flou, le “how” devient une loterie.

Au prochain épisode : Principe #4 — « Clarifiez vos critères d'acceptation » : comment éviter le “succès à géométrie variable”.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Aujourd’hui, deuxième épisode des 20 principes directement applicables par les chefs de projet.

Principe #2 : « Pensez à vos objectifs stratégiques. »

Dit autrement : un projet qui ne sert pas la stratégie, c’est juste de l’activité bien documentée.

Je te donne une scène classique. On te demande de lancer un projet. Tu poses des réunions, tu fais un planning, tu ouvres un registre des risques… tu fais le boulot. Et puis, trois mois plus tard, quelqu’un arrive et dit : « On ne devrait pas faire ça… ce n’est plus la priorité. Et en fait, ça ne correspond pas à ce que la société veut faire. »

Ce n’est pas un problème de planning. C’est un problème d’alignement. On se trouve là devant un projet qui a été initié par un Top Manager pour son agenda personnel, comme tremplin pour sa carrière, et pas parce que l'entreprise en avait besoin.

Ma version “bon sens” du principe : avant de gérer le projet, assure-toi qu’il sert une intention.

Trois questions qui évitent de bosser pour rien :

1. Quel objectif stratégique ce projet sert-il ? (un vrai objectif, pas un slogan)

2. Quel indicateur montrera que l’objectif progresse ? (un KPI utile, pas décoratif)

3. Qu’est-ce qu’on arrête / qu’est-ce qu’on change si la stratégie bouge ? (sinon tu subis)

Et c’est là que Project Cockpit devient pratique. Parce que on commence par dé"finir les objectifs stratégiques de l'entreprise et du portfolio, et ensuite, on relie le projet à un objectif, on relie les livrables à de la valeur, et quand il faut arbitrer — scope, délais, budget — on n’arbitre pas “à l’instinct”. On arbitre par rapport à l’objectif.

Conclusion : un chef de projet n’est plus un gestionnaire de tâches. C’est un gardien de la direction. Quand l’objectif est clair, tu peux dire non, tu peux prioriser, et ton projet cesse d’être une liste… il devient un levier.

Outro (option)

Au prochain épisode : Principe #3 — « Ask why things are done » : comment déminer les exigences absurdes avant qu’elles ne deviennent ton backlog.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Aujourd’hui, premier épisode relatifs aux 50 principes pour tout gérer au presque. Durant les 20 premiers, je vais me focaliser sur les principes directement applicables par les chefs de projet.

Principe #1 : « Démarrez vos projets par la fin »

Dit autrement : si vous ne savez pas où vous voulez arriver, vous pouvez être organisé comme la NASA… et totalement à côté de la plaque.

Je vois souvent des projets qui démarrent par :

• un planning,

• des réunions,

• un RACI,

• des tickets,

• des tableaux…

Et pourtant, quand on demande : « À la fin, on doit avoir quoi, exactement ? » Silence… ou réponse floue.

Alors voilà ma version “bon sens” du principe : décrivez la fin comme si vous étiez déjà arrivé.

Un bon objectif, ce n'est pas : « on aura amélioré l’expérience client ».

C'est: « le client peut faire 3 opérations par minutes, sans appeler le support, et on le mesure le mesure par le nombre de transactions introduites à l'heure à savoir 180. »

Trois questions qui sauvent des semaines :

1. Qui accepte le livrable à la fin ? La personne qui a l’autorité de dire oui… ou non.

2. Quel est précisément livrable qui doit exister à la fin ? Un truc qu’on peut montrer, tester, utiliser.

3. Comment saurez vous que c'est le bon produit? Pas « on verra ».

Et c’est là que Project Cockpit devient pratique : Dès le démarrage du projet, on pose l’objectif de fin, on le relie à des livrables, on attache des critères d’acceptation… et tout le reste devient plus simple. Le planning n’est plus un pari : c’est une conséquence. Pour réaliser le planning, comme on est déja à la fin, on se contente de se retourner et de voir le chemin parcouru entre l'étape de démarrage et le résultat obtenu.

Conclusion : commencer par la fin, ce n’est pas une philosophie. C’est une assurance anti-flou.

Comme tous les principes présenté, il n'est pas nouveau, il existe depuis des centaines d'années. Buster Keaton, réalisateur de cinéma de génie l'appliquait lui-même. Il définissait le début de son film, la fin et le reste du film devenait très simple à réaliser.

Au prochain épisode on passe au Principe #2 : comment relier un objectif stratégique à un projet sans tomber dans le blabla — et comment Project Cockpit te force à rester concret.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Alors voilà, nous arrivons à la 6ème et dernière semaine de l'annonce de mes projets dans le cadre de Project Box. Rassurez vous. J'ai encore bien d'autres projets privés mais ils sortent du cadre de ce podcast.

La question que je me pose aujourd'hui est la suivante: « Pourquoi les principes simples sont-ils ceux que l’on applique le moins en entreprise ? »

Après trente ans de projets, j’ai remarqué une chose assez troublante. Plus un principe est simple… moins on a envie de l’appliquer.

Pas parce qu’il est faux. Mais parce qu’il est évident. Et comme c'est évident, c'est juste trop simple pour être sérieux. Alors on complique. On ajoute des couches. Des processus. Des outils. Des réunions.

J’ai écrit "50 principes pour tout gérer ou presque" pour rappeler une chose basique : nous ne nous plantons pas par manque de méthodes sophistiquées. Nous nous plantons parce qu’on ne respecte pas les fondamentaux.

La version 2 de ce livre assume enfin ce que je pensais déjà à la version 1 : un principe n’est utile que s’il est compris, incarné… et appliqué.

Ce podcast marque aussi le lancement du podcast « 50 principes » dans QIRI. Un principe par épisode. Court. Concret. Vécu.

Pas pour expliquer comment être parfait. Mais pour aider à être un peu plus lucide.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Question de l’épisode

« L’IA va-t-elle rendre les project managers inutiles… ou révèle-t-elle surtout leurs vraies faiblesses ? »

Soyons clairs dès le départ. L’IA ne va pas sauver vos projets. Et encore moins vos réunions. Et elle ne vas probablement pas vous remplacer. Du moins pas totalement.

Par contre, elle peut vous éviter une quantité impressionnante de travail inutile. Ce qui, dans la vraie vie d’un chef de projet, est déjà une forme de miracle.

Ce qu’on ne vous dit pas toujours, c’est que l’IA n’est pas là pour remplacer le project manager. Elle est là pour faire ce que personne n’aime faire : structurer, reformuler, comparer, synthétiser, challenger.

L’IA est très forte pour préparer. Très forte pour analyser. Très forte pour poser les bonnes questions.

En revanche, elle est totalement incapable de gérer :

• un sponsor changeant d’avis,

• un stakeholder passif agressif,

• ou une réunion avec sept personnes qui pensent toutes avoir raison mais qui ont en commun de n'avoir aucune idée du scope du projet.

C’est exactement pour ça que j’ai construit une formation IA pour project managers. Pas une formation gadget. Pas une formation “prompt magique en 10 minutes”.

Une formation pratique. Ancrée dans le quotidien. Qui montre ce que l’IA fait déjà mieux que nous… et surtout ce qu’elle ne fera jamais.

Une formation qui vous montrera comment appliquer les standards de la gestion de projet, sans avoir l'impression de faire autant de papier qu'un fonctionnaire du 19è sicle.

Parce qu’un chef de projet augmenté, ce n’est pas un chef de projet remplacé. C’est un chef de projet un peu moins fatigué.

Et non, l'IA ne remplacera pas les chefs de projet, mais elle pourrait bien remplacer ceux qui n'utlisent pas l'IA

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

« Les casse-pieds au travail : malchance… ou mécanique bien rodée ? »

On va commencer par lever un malentendu.

Quand je parle de casse-pieds au travail, je ne parle pas de personnages toxiques, ni de harceleurs, ni de psychopathes organisationnels.

Je parle de comportements ordinaires, du quotidien, parfaitement acceptables pris isolément, mais qui, dans un contexte professionnel, finissent par pourrir la dynamique.

Le collègue qui ,'e, a que pour 2 minutes mais qui vous fait perdre une demi-heure. Celui qui n'est pas pressé parce qu'il sera bientôt pensionné. Celui pour qui les diplômes, ça ne vaut pas l'école de la vie. Celui qui “veut juste réfléchir encore un peu”.

Des comportements normaux dans la vie courante, mais pénibles au travail.

Après trente ans de projets, j’ai appris une chose : ces comportements sont répétitifs, prévisibles, et surtout universels.

Même phrases. Même postures. Même effets.

On les retrouve partout : grandes entreprises, PME, administrations, start-ups “agiles”. Ce n’est pas une question de culture d’entreprise. C’est une question de nature humaine.

Et non, ces personnes ne sont pas méchantes. Elles sont souvent :

• anxieuses,

• mal positionnées,

• plus en accord avec la réalité,

• convaincues de bien faire,

• ou simplement prisonnières de biais cognitifs très banals.

Le vrai problème, ce n’est pas la personne. C’est le comportement répété, et notre incapacité collective à le reconnaître comme tel au travail.

C’est exactement pour ça que j’écris 50 modèles de casse-pieds au travail. Un livre sur les petits travers ordinaires, adaptés au monde professionnel, qui finissent par produire des dégâts très concrets sur les projets, les équipes… et l’énergie de tout le monde. Je voulais pouvoir plus facilement les identifier, comprendre leur point de vue et leurs raisons et finalement, trouver les outils pour les gérer sans avoir envie de leur taper dessus.

Parce que en mettant des mots sur ces comportements du quotidien, on arrête de les subir, On passe de réactif à proactif. Et ça fait toute la différence.

Comprendre ces comportements, ce n’est pas juger les gens. C’est arrêter de faire semblant de ne pas les voir et apprendre à les gérer.

Et en entreprise, c’est déjà un énorme pas en avant.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Pourquoi je fais une version 2 des 50 principes pour tout gérer ou presque

Bienvenue dans QIRI, l’émission où je réponds enfin aux questions que j’aurais dû me poser avant d’écrire la version 1 de ce livre.

Aujourd’hui : « Pourquoi refaire un livre que j’ai déjà écrit ? »

La réponse courte : parce que la V1 était correcte. La réponse longue : parce qu’elle était correcte… et c’est bien ça le problème.

1. La vérité que je n’avais pas assumée à l’époque

Quand j’ai écrit la V1, je voulais avant tout publier un livre. Étape symbolique. Accomplissement personnel. Et, soyons honnêtes, un peu de vanité professionnelle.

Résultat ? Un livre sérieux. Trop sérieux. Poli. Trop poli. Presque lisse.

Le genre de livre qui dit des choses intelligentes… mais sans jamais vraiment dire ce que je pense. Parce qu’à l’époque, je n’étais pas prêt à assumer mon humour, mon sarcasme, mon regard d’ancien combattant du management.

Et surtout : j’ai parfois l'impression d'avoir laissé l’IA écrire à ma place. Je n’étais pas l’auteur. J’étais le coordinateur. Probablement le chef d'orchestre d'une série d'agents musiciens.

2. Ce que j’aurais voulu écrire… mais que je n’ai pas osé

La V1 ne contient presque aucune anecdote personnelle. Aucun exemple grinçant. Aucun moment de vérité un peu gênant. Aucune de ces scènes absurdes qui font le quotidien du travail moderne.

En clair : Le livre ne me ressemblait pas.

Aujourd’hui, un an après j’ai changé mon point de vue. Je me suis autorisé à être moi-même :

• Sarcastique, et constructif ;

• Réaliste, et humain.

• Dur et juste

Et surtout : prêt à dire tout haut ce que je pensais déjà tout bas.

3. Ce que la V2 va vraiment apporter

La V2 ne sera pas une réédition cosmétique. Elle sera une réécriture profonde, fondée sur trois piliers :

1. Le vrai ton : le mien

Sarcasme assumé, humour de vérité, réalisme cru. Plus proche de mes formations. Plus proche de mes conférences. Plus proche de ce que je suis.

2. La vraie vie : la tienne et la mienne

Des anecdotes vécues. Des scènes de projets réelles. Des comportements absurdes (mais universels). Du management tel qu'il se passe vraiment, et non tel qu'il est raconté.

3. Le vrai cerveau humain : les biais cognitifs

Pour chaque principe : une explication simple, brillante, parfois désagréable, mais scientifiquement juste. Pourquoi on fait n'importe quoi. Pourquoi on se ment. Pourquoi on répète les mêmes erreurs. Pourquoi, parfois, on a besoin qu’on nous le dise franchement.

4. Pourquoi cette fois-ci, le livre pourra vraiment servir

Parce qu'il sera :

• plus incarné ;

• plus mémorable ;

• plus utile ;

• plus drôle ;

• plus honnête ;

• plus profond ;

• plus humain;

• plus MOI.

Et surtout : parce que j’écris enfin le livre que j’aurais voulu lire au début de ma carrière, pas celui que j’ai cru devoir écrire en tant que « professionnel sérieux ».

La V2 ne sera pas parfaite. Mais elle sera vraie. Et c’est déjà beaucoup.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Fallait-il vraiment construire un 384e outil de gestion de projet?

Bienvenue dans QIRI, l’émission où l’on pose des questions qui piquent un peu… mais auxquelles il vaut mieux répondre franchement.

Aujourd’hui : Fallait-il vraiment construire un 384e outil de gestion de projet ?

Réponse courte : oui. Réponse longue : oui — et c’est même surprenant que personne ne m’ait demandé plus tôt.

Parce que soyons honnêtes : les outils de gestion de projet sont souvent pensés pour un seul profil. Généralement, le chef de projet. Parfois, le PMO. Quasiment jamais pour le sponsor. Et encore moins pour les trois en même temps.

Résultat :

• le chef de projet se bat avec l’outil,

• le PMO se bat avec les données,

• le sponsor se bat pour comprendre les deux.

Ajoute à ça le vrai quotidien :

• des priorités qui changent comme la météo,

• des plannings qui s’effondrent au premier regard,

• des décisions prises trop tard ou trop tôt,

• et une quantité d'informations réparties dans dix outils différents.

Mais la vraie raison derrière Project Cockpit n’est pas technique. Elle est pédagogique.

Depuis des années, mes apprenants me posent LA question : « Tout ce que vous expliquez… comment on le fait en pratique ? »

Et à chaque fois, je me retrouvais à bricoler des exemples, des modèles, des démonstrations. Parce que l’outil idéal n’existait pas.

Alors j’ai arrêté de l’attendre. Et je l’ai construit.

Un outil pensé pour le chef de projet, pour le PMO, pour le sponsor.
Un outil conçu pour montrer, expliquer et faire. Un outil qui répond à la question que j’entends depuis 20 ans : « Comment on fait… concrètement ? »

Voilà pourquoi Project Cockpit existe. Pas pour être « le 384e outil », mais pour être le premier outil pratique, pédagogique et utilisable par les trois rôles en même temps.

Dans le prochain épisode : "Les 50 principes pour tout gérer ou presque, ce que j’ai appris en ne les appliquant pas toujours. Et pourquoi j'ai décidé de les faire évoluer."

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.