Mes livres de référence

Il m’arrive souvent que des personnes me demandent qu’elles ont été mes sources d’inspirations, mes influences. Je vais y répondre en partageant la liste des livres qui ont eu un impact sur moi. Il n’y a pas de notation particulière, pas de position préférentielle dans cette liste, si ce n’est que j’ai essayé de la rendre digeste en créant des catégories. Cette liste est relativement longue et pourtant je suis certain qu’il manque quelques pépites, alors n’hésitez pas à me les proposer 😉

IMG_5046

Leadership & Management

Change & Culture

Business / Innovation

Product development / Digital

Méthodologies Agile / Lean

IT

Efficacité personnelle

Personal branding

Biographies

 

De l’importance du cadrage de projet

Préambule
Cet article est une dédicace à Esther Derby (http://www.estherderby.com/) qui m’a réellement influencé lors de son intervention à l’USI 2012 où elle y a présenté le concept de «60/30/10».

Je vous encourage à revivre cette présentation grâce à nos amis de @USIEvents qui ont re-publié cette vidéo en un temps record! 


Et n’hésitez pas à visiter le site Youtube de l’USI pour encore plus de vidéos.

Le principe de 60/30/10

Lors de sa présentation, Esther se basait sur une étude menée par J. Richard Hackman (cf lien en fin d’article) dans laquelle il démontre au travers de ses nombreuses recherches que l’efficacité d’une équipe est directement liée à la manière dont elle est construite et lancée :

  • 60% de l’efficacité d’une équipe se décide à la construction de l’équipe (avant son lancement)
  • 30% au lancement
  • 10% dans la suite du projet (après le lancement)

Par extension et projection sur la réalisation de projets informatiques, Esther en déduisait que beaucoup de choses se passent donc avant et pendant le kick off d’un projet, et qu’il faut par conséquent apporter une attention particulière à la manière dont on construit l’équipe.

J’en ai retiré 3 points importants :

  • le cadrage
  • la construction de l’équipe
  • le lancement (ou kick off)

Afin que cet article ne soit pas trop long, je vais surtout parler du cadrage. Je reviendrai dans un autre article sur les 2 autres points.

De l’importance du cadrage

Combien de fois ai-je fait le constat qu’un projet était parti trop vite, sans réel partage d’une vision claire, des enjeux, des échéances clés, de l’attente des sponsors, voire des moyens alloués, de l’architecture globale ou encore de l’organisation? Un nombre bien trop important, j’en ai peur… Fort de ce constat et de la mise en perspective d’Esther, nous avons formalisé, au sein de ma direction, ce qui se passe en amont d’un projet sous la forme d’un cadrage, dont l’objectif principal est de lancer le projet sur de bons rails et de le sécuriser.

Qu’est-ce qu’un cadrage?

« Une préparation réalisée en temps contraint, au cours de laquelle se succèdent un certain nombre d’activités et d’ateliers permettant d’aligner tout le monde autour de thématiques structurantes, qui se termine par un livrable global et synthétique pour validation et démarrage effectif du projet  »

Allez, déconstruisons cette définition!

Réalisé en temps contraint

Il est important de bien cadrer mais il est tout aussi important de réellement démarrer le projet! Un cadrage trop long, avec trop de temps passé à définir et décrire le projet, peut être tout à fait contre-productif. Il faut donc trouver le bon compromis. L’idée ici est de se contraindre par le temps et de se dire que ce n’est probablement pas grave si on n’a pas eu le temps de TOUT cadrer. Cela permet surtout de se concentrer sur l’essentiel.
Alors, combien de temps allez vous me demander pour un bon cadrage? Et bien, cela dépend beaucoup du contexte, de la complexité du projet, de l’âge du capitaine et tout et tout. Bon, de mon expérience, je pense qu’il est possible de cadrer la plupart des projets entre 4 à 6 semaines. Finalement, ce qui contraint le plus un cadrage est souvent la disponibilité des sachants et des sponsors!

Des ateliers pour détailler les thématiques structurantes

Comme le montre le schéma suivant, le cadrage comporte 6 ateliers permettant de dégager les éléments les plus structurants des thématiques suivantes :

Cadrage de projets

De façon à obtenir une meilleure efficacité, je vous recommande de contraindre dans le temps chaque atelier, de vous assurer de la disponibilité des bonnes personnes (notamment le sponsor) et de faire valider les résultats de chaque atelier au plus tôt. Les ateliers peuvent durer 2 à 4 heures. De mon expérience, il est quasiment impossible de mener les ateliers en parallèle puisqu’ils impliquent souvent les mêmes acteurs. Je vous conseille donc de les réaliser dans l’ordre présenté ci-dessus. Par contre, il n’est pas impossible que le résultat de certains ateliers viennent influencer ce qui a été défini dans un atelier précédent. C’est même une évidence et il faudra souvent plusieurs aller-retours avant d’obtenir une version aboutie. C’est normal et logique. Par ailleurs, certaines thématiques peuvent nécessiter plusieurs ateliers, ou même une préparation adaptée. Par exemple, l’architecture d’une nouvelle application peut donner lieu à plusieurs ateliers, voire à la réalisation de preuves de concept (POC) permettant de valider la faisabilité de certaines hypothèses techniques.
Afin de conserver cet article lisible (not tl;tr), je décrirai ces différents ateliers dans un prochain article.

Aligner tout le monde

Le cadrage, au travers des ateliers, va permettre d’aligner un nombre important d’acteurs clés du projet sur un même objectif. Cela concerne souvent 4 populations différentes, qui peuvent être mélangées en fonction de votre organisation :

  • le fonctionnel (aussi appelé Métier ou MOA)
  • le marketing
  • la technique (aussi appelé MOE)
  • l’exploitation (aussi appelé Production ou Opération)

Au-delà de ces acteurs opérationnels, il faut aussi s’assurer que les « décideurs » seront impliqués et informés des orientations choisies. Je peux vous assurer que cette tâche n’est pas la plus simple!

Un livrable global et synthétique

Le livrable est dit « global » puisqu’il va contenir l’ensemble des éléments structurants dans un seul et même document. Malgré cela, le document doit être le plus clair et synthétique possible. Je vous encourage à utiliser beaucoup de schémas qui, selon l’adage bien connu, valent mieux que de longs discours! A partir de cette présentation, vous allez pouvoir réaliser un poster synthétique du projet que vous collerez au mur, et tout autre présentation que vous aurez à faire en l’ajustant en fonction de votre public.

Validation

Il est fondamental que le cadrage soit validé par les décideurs de votre organisation. De mon expérience, les points les plus critiques et qui nécessitent une attention particulière, sont :

  • l’organisation : assurez vous que les acteurs positionnés sur les rôles de sponsor, Product Owner, possèdent à la fois la pertinence et les mandats nécessaires.
  • les ressources ou le budget : assurez vous que le budget alloué est légitime et pertinent. Attention aux projets qui souhaitent partir coute que coute, avec un budget ou un planning sous-taillé… Vous en payerez toujours les conséquences. (cf l’article sur la planification réaliste).
  • l’architecture : assurez vous que l’architecture proposée respecte les standards de votre entreprise ou au moins que vous assumez en connaissance de cause que cela ne soit pas le cas.

Démarrage effectif du projet

Du livrable, vous allez pouvoir en tirer une présentation de communication pour le kick off. Ce kick off est donc le prochain moment clé qui va permettre à toute l’équipe de se mettre en mouvement et démarrer le projet. Mais ça, c’est une autre histoire 😉

Pour en terminer sur le cadrage, j’ai toujours en tête une phrase qui m’aide à obtenir le bon état d’esprit:

L’important n’est pas tant le résultat que le chemin que nous parcourons ensemble!

PS: je tiens à remercier Jean-Claude Grosjean (@jcQualitystreet) et Guillaume Duquesnay (@duquesnay) avec qui j’ai la chance de collaborer au quotidien et qui ont largement participé à ce travail de formalisation.

Quelques références de livres ou ressources qui m’ont influencé sur ce thème :

Collaborative Intelligence: Using Teams to Solve Hard Problems - J. Richard Hackman

Collaborative Intelligence: Using Teams to Solve Hard Problems – J. Richard Hackman

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman

Monsieur le DSI, vous voulez des plannings réalistes?

Dans mes expériences passées et dans mon rôle actuel, j’ai vu passer de nombreux projets informatiques. Et bien sur, j’ai été témoin d’un nombre non négligeables de dysfonctionnements… Avant de vous ennuyer avec des considérations pragmatiques et pourtant un peu « théoriques », je vais commencer par une anecdote personnelle.

Monsieur le DSI, vous voulez des plannings réalistes?

Elle date du temps où j’oeuvrais en tant que consultant pour le compte d’une société d’assurances. Le DSI (un homme que je respecte au plus haut point) m’avait demandé de l’aider à monter une cellule d’analyse des risques. « Tu comprends, Alain, le portefeuille de projets est tellement grand que j’ai besoin d’aide pour identifier les risques importants dans les projets. J’en ai marre des projets qui passent du jour au lendemain du VERT au ROUGE sans que l’on n’ait rien vu venir… Tu peux aller voir n’importe quel projet, rentrer dans n’importe quel comité de pilotage. Tu dis juste que tu viens de ma part. » J’ai été poli, je me suis toujours annoncé.
Un jour, je vais voir un chef de projet et je lui demande de me montrer le planning de son projet. Le planning allait en se réduisant avec beaucoup de temps pour les spécifications, la conception puis moins de temps pour les développements et vraiment plus grand chose pour les tests de recette. Oui, la méthode était bien une cascade et là, ça chutait sec!
Moi: « Ne penses-tu pas que ton planning n’est pas réaliste? »
Lui : « Ben, si, je sais bien… On finit toujours les développements sur les phases de recette et on déborde sur le prochain lot du projet… C’est comme ça… »
Moi: « Mais, puisque tu le sais, pourquoi tu ne fais pas directement un plan réaliste? »
Lui : « Ben, c’est que les Managers veulent voir ces dates là! »
Moi : « Tu leur as vraiment demandé aux managers? Tu leur as dit que le planning n’était pas réaliste? »
Lui : « Non, c’est pas la peine, toute l’équipe le sait déjà. Et puis, on a fait un chiffrage initial et franchement, ce n’est pas facile, j’ai du mal à être précis… Bref, je ne sais pas justifier que ce n’est pas réaliste tant qu’on n’a pas tenté… Mais, bon, je suis d’accord, là on sait déjà qu’on ne va pas y arriver… »
Moi : «  Bon, je te propose que tu gardes ce planning pour le moment, mais prépare moi aussi un planning qui te semble le plus réaliste possible, en prenant en plus un peu de marge en cas d’imprévu. Moi, je m’occupe du reste. »
Lui: «  Eh! Déconne pas, je vais perdre mon job moi!! »
Moi : « T’inquiète… »
Je le laisse et je vais voir le DSI. Je toque à la porte. « ENTREZ! » Je rentre et lui demande: « Est ce que tu veux des plannings réalistes ou pas sur tes projets? »
Evidemment, vous devinez facilement sa réponse. Le plus rigolo est qu’une fois que nous avons mis au point un planning « réaliste », nous sommes allés le présenter aux autres projets connexes. Tous ont eu la même réaction : « Ah, mais si on peut maintenant le dire, nous aussi notre planning n’est pas réaliste!!! »

Donne un chiffre (ou une date) et il sera gravé dans le marbre!

Cette anecdote amusante, et pourtant tout à fait réelle, illustre bien 2 phénomènes : 1/ il est difficile d’estimer et 2/ il arrive fréquemment que les chefs de projet planifient ou chiffrent en fonction de ce qu’ils pensent que les managers attendent d’eux… Le plus dramatique est que ce jeu de dupes s’installe facilement par un phénomène assez connu : celui de l’annonce initiale. Enoncez un chiffre, une date, et celui-ci sera pris comme s’il avait été gravé dans le marbre! Ce phénomène est d’ailleurs bien connu puisqu’un bon négociateur n’énoncera jamais le premier chiffre et attendra que l’autre commence en premier. Cependant, nous ne sommes pas en train d’acheter une voiture ou une poterie au souk de Marrakech mais bien de faire une première estimation d’un projet informatique. Et il existe tellement de facteurs qui peuvent impacter grandement sa réalisation (la compréhension du besoin, la complexité du projet, la vélocité de l’équipe, les imprévus, les changements…) qu’il est finalement logique de ne pas pouvoir être précis. Mais, donne un chiffre et il restera…

Le biais du chiffrage budgétaire

Dans les grandes entreprises, arrive à un moment ou à un autre, le moment où « il faut faire les budgets pour l’année prochaine». A cela, rien d’illogique bien sur, surtout que l’objectif n’est pas d’être précis mais de fonctionner avec des grosses masses et de prévoir le budget nécessaire pour accomplir les projets alignés sur les grandes orientations stratégiques. On découpe donc ce budget en projets d’investissements, et on essaie de qualifier, « à la grosse louche » ou «  au pif », ces projets. La question n’est d’ailleurs pas tant de savoir combien coute tel ou tel projet mais plutôt d’évaluer combien on est prêt à investir. Et surtout, on se donne une orientation pour un budget global qui doit avoir du sens mais aussi de la souplesse pour pouvoir arbitrer les projets en fonction des aléas. Le premier biais est que lorsqu’on réalise cet exercice, on propose des enveloppes et, ce qui doit arriver arrivera, le manager en charge d’une enveloppe considèrera qu’il a exactement le chiffre qui est inscrit dans le budget. Donc, au mieux, il va dépenser tout le budget même si le projet peut coûter deux fois moins cher ou pire, s’il doit coûter deux fois plus cher… Bien sur, il existe quelques pratiques qui permettent de contrôler cette situation, comme de réserver une poche budgétaire, le budget du DSI, qui permettra de couvrir les coups durs (5 à 15%). Ma préférence va à un pilotage mensuel (au pire trimestriel) permettant de redéfinir et de communiquer fréquemment les priorités et les évolutions des enveloppes budgétaires.

Le chiffrage initial 

Car il en faut bien un, j’en suis le premier convaincu. Il est important de savoir s’il est intéressant d’investir, de savoir si le jeu en vaut la chandelle, s’il y a un potentiel retour sur investissement. Il faut bien se poser la question « Combien peut bien nous coûter la construction de ce produit/service/application? »
Plusieurs techniques existent, mais je vais en décrire uniquement trois que j’ai le plus souvent utilisées.

La technique de l’ingénieur
Dans cette technique, vous découpez votre projet en grandes fonctionnalités, puis vous décomposez chaque fonctionnalité jusqu’à arriver à des tâches unitaires, que vous estimez Simple, Moyenne ou Complexe à réaliser. En fonction de la nature du langage de programmation, de l’architecture, de l’âge du chef de projet, vous allez définir un nombre de jours.homme à chacune des catégories (S/M/C). Vous pouvez même appliquer des poids de complexité pour atténuer ou amplifier certains phénomènes (par exemple, si vous avez un nombre de fonctionnalités identiques, vous pourrez gagner du temps pour les réaliser en industrialisant le processus).
J’ai participé à plusieurs exercices de ce genre mais un seul retient mon attention tellement il est significatif de ce type de méthode. Lorsque j’étais consultant dans une grande SSII réputée pour son sérieux (totalement justifié en l’occurrence), une méthode de ce style a été mise au point parce que des écarts importants avaient été observés entre le chiffrage des projets au forfait et leurs réalisations effectives. Et cela, rarement au profit de l’entreprise… Le but était de proposer une méthode permettant de se rapprocher au plus proche du Chiffre exact. Afin de calibrer la méthode, il a été demandé à 3 manageurs de projets expérimentés (à eux trois, cela dépassait allègrement les 60 ans d’expérience!) de chiffrer avec cette méthode un projet qui avait d’ailleurs déjà été réalisé dans l’année. Donc, ils en avaient tous une connaissance suffisante. A la sortie, le plus optimiste était à 800 j.h et le plus pessimiste à 2400 j.h. 3 fois plus! Qui a tord, qui a raison? Je vais y répondre par la suite.

La technique de la comparaison 
Une autre technique consiste tout simplement à comparer le projet que vous devez réaliser avec un projet que vous avez déjà réalisé et qui y ressemble (un peu). Avec bon sens, vous pouvez évaluer si vous pensez que le projet sera globalement plus ou moins compliqué, que le contexte est plus ou moins favorable, que le projet comporte plus ou moins de risque. Vous remuez le tout et vous sortez un chiffre.

La technique par l’équipe type
La troisième technique consiste à définir l’équipe type que vous pensez avoir besoin pour faire le projet. Si par exemple, je pense avoir besoin d’une équipe composée d’un chef de projet fonctionnel (product owner), un chef de projet technique (scrum master), un technical leader et de 3 développeurs pendant 6 mois, alors cela me fait entre 600 j.h et 700j.h.

Comparer les estimations

Je n’ai pas réellement de préférence sur les techniques de base présentées précédemment même si j’utilise de moins en moins la première technique, et que je privilégie plutôt la combinaison des deux dernières. Surtout, j’essaie de challenger mon chiffrage en demandant à d’autres personnes de le faire aussi, dans leurs coins, puis de comparer nos résultats.

Une estimation est prévisionnelle 

Je répète : une estimation est prévisionnelle! Cela reste donc une ESTIMATION! Et, par définition, les estimations sont toujours fausses, même si elles sont nécessaires. S’il existait une méthode scientifique pour faire un chiffrage, cela se saurait maintenant! De plus, elle est PREVISIONNELLE, ce qui veut dire que c’est la meilleure estimation que l’on sait faire au moment où on l’a fait. En fonction des circonstances, cette estimation peut tout à fait changer et c’est bien normal. Et pourtant…

La planification initiale

Une fois chiffré, on peut se lancer dans la planification initiale du projet afin
La méthode que vous allez utiliser pour votre projet, quelle soit agile ou en cascade va bien sur impacter le rythme du projet mais ne devrait pas nécessairement impacter votre planning initial. En effet, dans un planning initial, il parait important de définir les jalons, les livraisons importantes de votre projet/produit/service/application. Depuis quelques années, les méthodes agiles et lean ont d’ailleurs largement influencés la construction de ces planning initiaux en proposant de commencer par un MVP (Minimum viable product), l’ensemble minimum des fonctionnalités qui permettent de mettre en production et de voir si le produit trouve son public. Evidemment, cette approche est tout à fait adaptée pour un service Internet et un peu moins pour une application de gestion, meme si on peut toujours s’en inspirer pour réduire le time to market et se concentrer sur les 20% des fonctionnalités qui sont utilisées dans 80% des cas.

Planifier avec « pragmatisme »

L’art de la planification est pourtant simple :
– faites un premier chiffrage (timeboxé)
– affinez avec un cadrage projet qui précise les éléments clés du projet : la vision, le périmètre, l’architecture de la solution (fonctionnelle et technique), l’organisation (méthode et compétences requises), les risques
définissez dés le départ la fréquence à laquelle vous allez réévaluer le planning et les estimations du projet -> c’est la clé
– staffez l’équipe et commencez à travailler
– au bout de quelques semaines (itérations?), révisez votre planning et votre chiffrage 
– ajustez en conséquence et informez vos sponsors
continuez et recommencez 

«  Toi, chef de projet, fais des plannings réalistes et laisse aux responsables le soin d’arbitrer. » 

Et pour finir sur une note positive, des études scientifiques démontrent que les personnes qui évaluent le mieux sont soit déprimées soit régulièrement pessimistes 😉

Quelques références de livres qui m’ont influencé sur ce thème :

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman

The Mythical Man-Month - Frederick Brooks

The Mythical Man-Month – Frederick Brooks

Behind closed doors: Secrets of Great Management  - Esther Derby & Johanna Rothman

Behind closed doors: Secrets of Great Management – Esther Derby & Johanna Rothman

Waltzing with bears : Managing Risk on Software Projects - Tom DeMarco

Waltzing with bears : Managing Risk on Software Projects – Tom DeMarco

Quality software Management: Systems Thinking - Gerald M Weinberg

Quality software Management: Systems Thinking – Gerald M Weinberg

Psychologie sociale pour managers - David G Myers

Psychologie sociale pour managers – David G Myers

Il n’y a pas d’ingrédient secret!

Mais un bon leader peut en créer l’illusion!

« There is no secret ingredient. To make something special, you just have to believe it’s special! », 
Non, cette phrase n’est pas de Eckart Tolle ou du Dalaï Lama mais de Kung Fu Panda, ou pour être plus précis du père de Kung Fu Panda (enfin, c’est pas vraiment son père mais ca, Kung Fu Panda ne le sais pas, chut!!), le cuisinier qui fait une soupe tellement appréciée que tout le monde pense qu’il utilise un ingrédient secret.
http://www.youtube.com/watch?v=K7DnFGdqT8c

Lorsque j’ai revu Kung Fu Panda pendant les fêtes de fin d’année, tout de suite, cette phrase m’a fait penser à ce que j’ai pu observer en accompagnent des équipes sur des projets IT. Et aussi, au rôle particulier qu’un leader pouvait jouer auprès de ces équipes. Bien sur, comparaison n’est pas raison, et la mienne de comparaison n’est peut-être pas fabuleuse mais je m’explique quand même (et après tout, je fais ce que je veux, non?).

En réalité, il arrive fréquemment que les équipes se focalisent sur les freins d’un projet. N’avez vous jamais entendu : « Mon dieu, on ne va jamais y arriver! », « On n’aura jamais le temps! », « On manque de ressource! », «  Le projet est trop gros! », « Le sujet n’est pas clair! » ( choisissez ou ajoutez votre « excuse! » )

Cette peur peut paralyser une équipe entière

Comment l’éviter?
Beaucoup de méthodes proposent de détailler le projet, voire de le détailler encore plus, de découper en tâches plus fines, de planifier, planifier, planifier… Ca peut aider.

Personnellement, j’ai trop observé de temps perdu à vouloir trop détailler en amont, demander à des gens qui ne savent pas (objectivement) décrire des « spécifications détaillées », de planifier pour rien… Je préfère une approche beaucoup plus pragmatique, initialisée par un cadrage minimal (tout du moins time boxé), suivi d’une mise en action immédiate et d’un process d’amélioration continue permettant l’ajustement. Ca donne donc:

On priorise -> On choisit -> On fait -> On livre -> On analyse -> On ajuste -> On recommence

Bref, si vous n’avez toujours pas compris de quoi je parle, c’est bien des méthodes agiles.

Mais, cela n’est parfois pas suffisant. Le process, la méthode sont importants mais si on y injecte l’ingrédient secret, c’est encore mieux. Et cet ingrédient secret, pour une équipe, c’est avoir la certitude qu’elle peut s’appuyer sur un manageur agile, un leader, capable de la soutenir dans les moments importants.

Ce leader doit être capable de
– Ecouter de manière active (vraiment!) les remontées de l’équipe
– Rassurer quand l’équipe se pose des questions
– Protéger l’équipe de tout le bruit et les perturbations qui l’entourent afin qu’elle se focalise sur ce qu’elle a de plus important à faire

En gros, être la courroie de transmission avec le top management, en mettant ce dernier devant ses propres responsabilités lorsque cela est nécessaire («  vous demandez le beurre et l’argent du beurre! Choisissez ce qui est le plus important pour vous! »).

Aux yeux de l’équipe, ce leader devient l’ingrédient secret

Fort de ce soutien, et une fois la mise en marche enclenchée, l’équipe va prendre confiance en elle et éviter de perdre du temps sur des sujets sur lesquels elle n’a pas de prise.

Quand tu n’as plus le temps, prends le temps!

Au début des années 2000, j’ai décidé de me lancer dans une carrière de consultant pour élargir mon expérience. Cela m’a permis de rencontrer des entreprises avec des contextes organisationnels et technologiques bien différents. Je m’étais spécialisé dans les frameworks Java et dans l’architecture applicative. Ce sujet était très porteur à l’époque.

La SSII pour laquelle je travaillais à l’époque avait aussi une activité à l’international et notamment en UK. Parlant la langue, j’étais enchanté à l’idée d’aller aider l’entité anglaise à développer son business et a les faire monter en compétences sur Java.

Le soucis est que mes compétences ont commencé à être reconnues mais surtout connues par différentes équipes. Et forcément, un jour je me suis retrouvé sous l’eau

J’avais déjà 3 missions en parallèle et j’étais sur le chemin d’une réunion que l’on avait planifié à 7h30 du matin car je n’avais plus de dispo dans mon agenda.
En entrant dans les bureaux du siège de cette société où se trouvait la réunion, je croise le directeur de l’international.
Lui: « Bonjour Alain, comment vas tu? Viens prendre un café dans mon bureau. »
Moi: « J’aimerai bien, mais j’ai une réunion qui va démarrer… »
Lui: « Si tôt! Sur quel projet? »
Moi: « Ben, c’est un nouveau projet qui va démarrer et ils veulent m’impliquer pour les aider… »
Lui: « Mais je croyais que tu étais déjà sur 2 projets pour les UK! »
Moi: « Euh… Oui c’est vrai, et j’ai aussi un autre projet en France… Mais là, ils m’attendent vraiment… »
Lui: « Alain, ce matin, je vais te faire un cadeau. Rappelle toi de cela: quand tu n’as plus le temps, prends le temps! »

On est allé à son bureau, il a appelé la salle de réunion et les personnes qui m’attendaient en leur disant qu’ils allaient devoir se débrouiller sans moi, et on a pris un café en parlant de tout sauf du business. Merci Xavier, je n’ai pas oublié cette leçon!

Parfois, on est sous l’eau et on n’arrive même plus à prendre le temps de souffler, de prendre un café… Lorsque cela vous arrive, cela veut dire que quelque chose ne va pas : vous gérez trop de tâches en parallèle, vous êtes mal organisé, vous ne savez pas déléguer…

7740077532_211ca33411_h

Lorsque cela m’arrive (évidemment que cela m’arrive!), je prends le temps d’un thé  (ceux qui me connaissent, savent ma préférence pour le thé) et j’essaie de comprendre ce qui ne va pas et comment ajuster mon process.

Lors de prochains billets, je partagerai avec vous certaine de ces pratiques qui marche pour moi pour mieux gérer mon activité.