Conseil en management

Plus de 350.000 visiteurs uniques...
1,4 million de pages vues...
300 articles publiés...
 
 
Coucou !

Bienvenue !

Ce blog a pour vocation de partager réflexions et expériences en matière de management. Clins d'oeil, analyses, trucs, débats, coups de gueule, réactions, commentaires, et... offre de services.
Bonne lecture, et n'hésitez pas à commenter...

Laurent
Artisan Consultant
Coaching en ligne

 
 
View Laurent de Rauglaudre's profile on LinkedIn

Recherche

Quelques bons bouquins...

Calendrier

Juillet 2009
L M M J V S D
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
<< < > >>

W3C

  • Flux RSS des articles
Samedi 24 mai 2008
Il était une fois...

J'étais alors responsable d'un projet qui consistait à faire que le cordonnier soit mieux chaussé. En clair, il s'agissait de transformer les employés Gemplus en premiers usagers des mille et une utilisations intelligentes de la carte à puce dans le monde professionnel. C'était il y a si longtemps... avant le fameux 11 septembre, vous rendez-vous compte !

Ce matin, j'entends ma Sandrine pester contre la multiplication des mots de passe à retenir... ça m'a rajeuni.

Or donc, en ces temps reculés, la petite équipe de développement fort créative que j'avais récupérée dans mon service, avait mis au point un prototype appelé "Smart Password". L'idée très simple m'avait plu, d'emblée. Il s'agissait d'utiliser une carte à puce branchée sur le PC, et dont la mission était d'enregistrer de manière sécurisée tous les mots de passe de la vie courante : applications internes ou internet. Nous avions lancé une opération pilote auprès d'une centaine d'utilisateurs ravis : désormais, il n'y avait que le code de la carte à retenir pour déambuler d'une application à un site internet, sans avoir à se préoccuper des mots de passe à présenter. La carte les stockait de manière sécurisée. The comfort, isn'it ?

La belle histoire devait trouver une fin heureuse. Avec toute mon équipe, nous entamâmes une opération "promotion/séduction" auprès de la direction générale : une demi-douzaine de présentations de tout ce que l'équipe avait mis au point, Smart Password mais aussi les autres applications du programme GemPrivilege. Tout le monde était emballé, et, anecdote suffisamment parlante pour la signaler, toutes les démos fonctionnèrent. Aussi incroyable que cela puisse paraître pour les experts du développement :-) Le bonheur...

Bilan formidable sauf que, sauf que... dans la coulisse se préparaient les grands chambardements de l'organisation de l'entreprise. Si l'enthousiasme des grands directeurs était patent, aucun ne souhaita endosser la responsabilité (le Sponsoring) du déploiement des applications dans l'entreprise. En substance, le message était : "super boulot de ton équipe Laurent, bravo ! Mais bon, j'ai d'autres chats à fouetter" (pauvres bêtes). Penauds, nous décidâmes donc d'arrêter totalement le projet. Toute l'équipe fût répartie dans d'autres entités de l'entreprise.
 
Quelques jours après cette tragique décision, je participai à une réunion produit. Le sujet : "faut-il tuer Smart Password ?" Le jeune développement tremblait dans ses lignes, la grandeur du marketing allait décider de son sort. Au milieu de la réunion (sentant mes démangeaisons de création d'entreprise me chatouiller), je lançai : "certes, vous pouvez décider d'arrêter le produit. Cela dit, si tel est votre décision, je suis intéressé à créer une start-up sur ce sujet". Un grand opérateur avait signalé son intérêt pour le concept, alors que nous n'en avions fait que peu de publicité. L'argument porta-t-il, je l'ignore. Toujours est-il que le comité produit décida de continuer le développement en rajoutant 2 ou 3 fonctionnalités "mineures".

Six mois plus tard, le produit était devenu tellement complexe - et par conséquent inopérant - qu'il fut abandonné.

Il alla donc rejoindre ces fameuses poubelles à projets des grandes entreprises. Elles sont pleines d'innovations étouffées dans l'oeuf...

<message dédié à Anthony, Christian, Cécile et les autres...> 
Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 3 commentaires - Recommander
Mercredi 24 octobre 2007
Cet article est un clin d'oeil à mes étudiants de l'IAE d'Aix...

Un jour, pour finir une première journée de formation sur le management de projet, je lance un dernier exercice en forme de transition pour la prochaine session :

"Réfléchissez 10 minutes en sous-groupe aux 3 raisons majeures qui selon vous, font que certaines équipes réussissent mieux leurs projets que d'autres. Et allez inscrire vos 3 raisons au tableau."

La quarantaine d'étudiants planche sur ce simple débat. Chaque équipe envoie un scribouillard au tableau, bientôt décoré de 6 * 3 caractéristiques des équipes performantes. A vrai dire que du bon sens, des constats clairs et pertinents, une bonne prise de conscience collective en quelque sorte. Alors que les écritures se terminent, un étudiant redescend rapidement l'amphi et corrige l'un des critères énoncés par son équipe. Il modifie : "avoir un bon leader" par "avoir un bon pilotage".

Je saute sur l'anecdote... Pourquoi cette modification ? Faut-il déduire qu'un bon projet peut être bien "piloté" sans pilote ? Pourquoi cette pudeur à détacher la réussite d'une équipe projet du fait qu'elle a un bon leader ? Peut-on imaginer que le bon pilotage du projet se fait "naturellement", sans influence et sans le caractère entrainant de son coordinateur ? Suffit-il d'avoir de bons outils de pilotage pour qu'un projet réussisse ?

Je suis convaincu que l'un des facteurs clés de succès d'un projet réside dans la qualité de leadership du responsable. Si j'ai sauté sur ce symptôme, c'est que je crois qu'on oublie ce basique de management : les outils ne sont rien s'il n'y a pas quelqu'un de lucide pour les utiliser au mieux, s'il n'y a pas un caractère pour entrainer les énergies de l'équipe.

Et je vais rapidement revenir sur ce sujet à propos d'outils...
Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 6 commentaires - Recommander
Mardi 15 mai 2007

Je pose cette question aux personnes qui assistent aux formations que j'anime en management de projet "quand dormez-vous mal ?". Et j'obtiens souvent ces réponses :

- à la fin, on s'approche de la conclusion, je suis sur tous les fronts, je dors mal...
- je dors mal pendant tout le projet, je suis stressé par la peur d'échouer...


Le symptôme de faire des insomnies à la fin ou pendant toute la durée du projet cache un problème de fond. Organisation, préparation, délégation, planification, relation au pouvoir, tout cela est en jeu.


Je milite pour les insomnies en début de projet !


Ce symptôme-là - les nuits sans sommeil du lancement - est révélateur de la prise en compte de l'ensemble des enjeux du projet :

- quels sont les risques ?
- comment vais-je réussir à atteindre les objectifs, ai-je suffisamment de moyens (humains, financiers, techniques, ...) ?
- quelles sont les étapes à franchir, comment se structure le planning ?
- qui sont mes alliés et mes adversaires dans ce projet ?
- la faisabilité technique a-t-elle été suffisamment évaluée ?
etc...

Et pour aller plus loin, le début du projet est le moment où l'on accepte "mollement" (on m'a demandé de prendre ce projet), ou "solidement". J'accepte si mon analyse me conduit à penser que j'ai tous les moyens et les pouvoirs de réussir - sous-entendu, si les conditions ne sont pas remplies, je dis non1.

Cela peut empêcher de dormir la nuit... Mon expérience m'a montré que les insomnies de début de projet étaient un gage de fort engagement et de réussite.

Bon, je retourne faire la sieste :-)

 

1 voir article "apprendre à dire un non positif"

Par Laurent DE RAUGLAUDRE - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 3 commentaires - Recommander
Mardi 6 février 2007
"Un beau schéma en dit plus qu'un long discours" a dit le prophète, je vous laisse donc apprécier celui-là - valable aussi bien en entreprise que pour ce qui concerne l'éducation des enfants...
Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 0 commentaires - Recommander
Lundi 5 février 2007

Dans la plupart des projets, le Chef de Projet consigne soigneusement le pourcentage d’avancement des taches. On a donc des pourcentages mathématiques et scientifiques d’avancement. L’avancement est mesuré au pourcent près. Franchement, ça me fait sourire.

 

J'ai fait cette erreur lors du premier projet que j'ai dirigé : je consignais les pourcentages d'avancement des taches chaque semaine avec l'équipe. Je ne pilotais pas, je relevais des compteurs. Et des compteurs qui ne voulaient rien dire.

 

Que veut dire 58% d'avancement ? Pourquoi pas 56 ou 59 ou 54,22 ? L'avancement d'une tache est-elle mathématique ? Si j'écris un programme informatique, dois-je compter l'avancement en faisant un rapport entre le nombre de lignes écrites et le nombre de lignes que je pense nécessaires pour finir le programme ? Si je construis un immeuble de 4 étages, est-on à 50% quand on a édifié 2 étages ? Si j'organise un colloque, quand suis-je avancé à 42% dans ma préparation ?

 

 

Peut-être existe-t-il des théories qui vont contredire mes propos, cependant… cependant, diriger un projet est avant tout une histoire humaine, ou la dimension risques est permanente.

 

De mon point de vue, le pourcentage d'avancement est une indication pas une absolue vérité. Plutôt que demander : "quel est l'avancement de la tache ?", il vaut mieux demander : "qu'est-ce qui est concrètement réalisé ? que reste-t-il à faire ? quand penses-tu avoir terminé ? quels sont les obstacles susceptibles de t'empêcher de finir à cette date ?" Dans la plupart des projets, un indicateur coloré par tache suffit :

 

Vert à cette tache ne pose aucun problème, elle sera finie dans les temps et le budget prévus.

Orange à cette tache pose quelques soucis, mais le responsable de la tache pense pouvoir s'en sortir.

Rouge à cette tache pose des problèmes, le responsable de la tache à besoin d'aide, d'arbitrage, d'implication du management.

 

On peut aussi définir un code simple d'avancement 20%, 40%, 60%, 80%, 100% qui correspond à des livrables clairement définis au début du projet. Mais 37% sincèrement, vous y croyez vous ?

 

Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 2 commentaires - Recommander
Jeudi 23 novembre 2006
Les vendeurs de logiciel de planification vont faire un autodafé de ce post (risque) ou vont m'apporter la solution que je cherche depuis 15 ans (opportunité). A ce jour, je n'ai pas trouvé d'outil de planification qui me convienne. Ne parlons pas de celui du géant de Seattle, je le trouve compliqué et suspect : il fait des choses, des calculs dans mon dos de Chef de Projet, sans que je sois certain que cela n'impacte significativement la logique de mon planning.

Je le dis et je le répête : le planning est le reflet des engagements de l'équipe projet. Il est donc construit en équipe, et doit être simple et compréhensible pour tous : l'équipe projet, le comité de pilotage, le client, le management. Simple veut dire : 20 jalons et 50 taches maximum (au delà on ne maitrise plus l'ensemble, et il convient de regrouper certaines taches et d'en faire des "sous-planning"), compréhensible veut dire que la formulation et la présentation sont claires et lisibles.

Alors, découragé de ne pas trouver THE logiciel, je suggère d'orienter le choix de mise en forme du PERT/CPM vers un outil purement de présentation. J'ai récemment fait l'acquisition de MindManager que je trouve très attrayant pour synthétiser le fruit des remue-méninges... Et je teste son usage pour faire un PERT/CPM. Voyez plutôt :

ou si vous ne voyez pas bien, téléchargez ici le même document au format Acrobat, ou ici au format MindManager. Il existe un outil de lecture des "maps" (un viewer) de MindManager que vous pouvez trouver à cette adresse, gratuitement.

L'avantage de cette présentation est qu'elle est très visuelle, facile à mettre en oeuvre. Le logiciel MindManager permet une navigation en gros plan d'un planning qu'on peut montrer en rétroprojection de manière spectaculaire et compréhensible par tous.

J'entends aller bon train les commentaires (sic) des férus des logiciels de planification :

- mais ce truc ne calcule rien !
- mais cela n'intégre pas les charges des équipes !
- et comment je passe au Gantt à partir de ce planning ?
Bref... retourne donc dans ta caverne !

Pour avoir récemment discuté avec un ingénieur d'une énorme société informatique leader mondial, ingénieur senior, expérimenté, plebiscité par ses clients, respecté pour la pertinence de ses analyses des enjeux projets, et qui m'a avoué utiliser "Word" pour faire ses planning, je me dis que nous serons au moins 2 dans la caverne.

Si MindManager ne calcule rien, je trouve que c'est une bonne nouvelle. Le Chef de Projet reprend son rôle sans être dominé par la machine, ou sans tomber dans les excès ludiques des logiciels qui ne représentent que leur propre logique, et non pas celle des engagements de l'équipe. Si cette proposition ne résoud pas la "charge" des équipes, je rappelle que le travail de planification est un travail de logique des interdépendances des taches dans le temps, et que la "charge" est une notion financière, dont les contraintes sont régulièrement arbitrées et  corrigées par le management. Prétendre  mélanger automatiquement dans un logiciel unifié ces 2 notions me parait souvent un défi illusoire - non pas dans la théorie - mais dans l'usage que font les Chefs de Projet de leurs outils. Et si on n'arrive pas simplement à passer de cette représentation PERT/CPM au Gantt, c'est peut-être une limite temporaire puisque MindManager offre un module Gantt associé.

Bref, vous m'avez compris (I hope), je suis pour la reprise du pouvoir du Chef de Projet sur les outils de planification.
Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 1 commentaires - Recommander
Mercredi 27 septembre 2006
Grâce à l'un de mes lecteurs (David... à qui je dédie cet article), je vais corriger un crime de mon ignorance. Depuis plus de 10 ans, quand je présente le diagramme de PERT (Program Evaluation Review Technique), je me trompe de nom de baptême. La méthode que j'enseigne n'est pas à proprement parler le PERT. Ai-je été trompé par mes lectures ou par l'utilisation il y a quelques années de Microsoft Project qui dénommait PERT, à tord, la représentation dont je parle dans l'article que j'ai écrit en mars 2005 ?

Selon David, "ma proposition" est la méthode CPM. J'ai fait des recherches - AFITEP, PMI, wikipedia, internet, bouquins projet... En effet, ce que j'explique se rapproche davantage de la méthode Critical Path Method --> voir le dictionnaire franco-anglais de l'AFITEP, ou NetMBA.

Je vais donc modifier mes outils de formation et ajouter une remarque dans mon article sur la méthode PERT.

En définitive, ce qui m'importe le plus n'est pas de défendre une méthode contre une autre. Ce qui m'importe n'est pas non plus de tenter de faire passer l'exhaustivité des méthodes aux participants des formations que j'anime. Ce qui me parait important est de produire un résultat en équipe, avec l'apport de chacun.

Mon constat est que travailler l'enchainement logique des tâches d'un projet avec des post-it sur un mur, en impliquant l'ensemble de l'équipe projet est un facteur clé de succès. On obtient ainsi l'engagement des contributeurs au résultat final, la production d'un planning à peu près logique, la résolution préventive de nombreuses incohérences. Pour parvenir à construire un tel planning ensemble, il faut suivre quelques étapes précises pour enourager la créativité de l'équipe et dégager les blocages sur la fameuse date de livraison au client. En planification initiale, proscrire l'ordinateur au profit de papier, crayon, gomme, scotch, grandes feuilles blanches, gomme-colle - ah les horribles choses de l'ancien temps - me paraît primordial.

Heureusement que j'ai de fidèles lecteurs pour corriger mes errements. Je continuerai donc d'insuffler le vent de la méthode de planification initiale en équipe sur le mur, en notant simplement qu'elle s'inspire des méthodes PERT et CPM.

Merci David :-)

Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 3 commentaires - Recommander
Lundi 6 mars 2006
Le Project Management Institute (PMI®) France-Sud section Provence organise en partenariat avec l’EGIM/Ecole Centrale Marseille son premier Forum qui se tiendra le mardi 28 Mars 2006 de 8 h 15 à 12 h 45, dans les locaux de l’EGIM, Technopole de Château Gombert sur le thème  :

« Le Management des Risques dans les Projets »

A cette occasion, je présenterai une conférence intitulée "les leçons oubliées de l'an 2000". Voici le résumé de mon intervention :



Une gigantesque onde de choc, une ébullition sans précédent a ébranlé la planète pendant la seconde moitié des années 90 : « les machines risquaient de ne pas passer l’an 2000, les horloges allaient s’affoler ».

Un effort colossal a été entrepris. Que reste-t-il de cette expérience ? Quelles leçons en tirer ? Et le bogue, mythe ou réalité ?

A partir de son expérience de direction du projet d’une société globale high-tech dans une situation très critique, l’intervenant propose quelques angles originaux de prise de recul par rapport à la gestion de risques tous azimuths (techniques, juridiques, financiers, commerciaux, etc.).


Pour tout renseignement et inscription au forum : pmi-provence@pmi-fr.org
ou par téléphone au 06.72.74.64.84 et sur le site  http://pmi-fr.org/france-sud

Venez nombreux :-)
Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 1 commentaires - Recommander
Mardi 14 février 2006
A l'heure de la "Powerpoint mania", il est rafraichissant de lire dans la langue de Shakespeare la règle du 10/20/30.

10 transparents maximum, présentation de 20 minutes maximum, une taille de caratère de 30 minimum.

Autrefois, le piètre orateur ânonnait, le nez penché dans le papier, son texte, sans âme. Aujourd'hui il se réfugie dans un déluge de transparents illisibles.  Et pour être sûr de capter l'audience, il regarde ses transparents au lieu de scruter dans les yeux de son auditoire, l'impact de son discours.

Bel exercice de synthèse que de réduire son nombre de diapo, ne garder que les mots essentiels, dessiner plutôt qu'écrire. Comme bien d'autres erreurs :-), j'ai produit des milliers de transparents depuis 15 ans. Récemment, j'ai réduit mon nombre de visuels de 180 à 100 pour une intervention de 3 jours sur le management de projet. Sans doute ma meilleure intervention sur le sujet d'ailleurs (applaudissements à la fin, ça fait plaisir).

A méditer en ces heures de communication débordante dans les entreprises...


Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 3 commentaires - Recommander
Vendredi 25 novembre 2005
De quoi s’agit-il ? A quoi cela sert-il ? Qui en est membre ? Qui l'anime, qui arbitre ? Quels sont les objectifs et la régularité de réunion de Comité de Pilotage ?

 

Encore une fois, si le Projet présente des enjeux forts, avec de lourdes interdépendances et contributions de plusieurs entités de l'entreprise, il peut être nécessaire de monter une équipe de pilotage. Cette équipe va servir de relais de pouvoir, va permettre de faire approuver au plus haut niveau les décisions majeures, les passages d'étapes. Les membres du Comité doivent donc être décideurs ou influents, concernés par le projet, avoir un pouvoir direct ou indirect sur les moyens affectés au projet.

 

Le Comité de Pilotage est formé en début de projet par le Sponsor en collaboration étroite avec le Chef de Projet. Dans la réalité, le Chef de Projet fait une démarche pour solliciter les responsables ou experts susceptibles de participer au Comité. Il s'appuie sur l'analyse faite avec le Sponsor. Bien souvent, le seul fait de citer le Sponsor comme dirigeant le Comité de Pilotage, suffit à motiver le futur membre à se joindre au Comité.

 



Les réunions de Comité de Pilotage se tiennent alors sous l'autorité du Sponsor, mais sont animées par le Chef de Projet. Celui-ci prépare les réunions avec en tête quelques idées forces:

 

- les réunions doivent être planifiées longtemps à l'avance (les membres sont des gens importants à l'agenda difficile);

- les présentations doivent être très synthétiques (tableaux de bord clairs et points cruciaux à discuter);

- le Chef de Projet doit aller "direct au but" (point n'est besoin de développer de grandes tirades, le Comité est là pour décider des sujets difficiles);

- le Sponsor ne doit rien découvrir pendant la réunion, car il sert d'allié du Chef de Projet en cas d'arbitrage difficile, et donc il ne doit pas avoir de surprise en réunion.

Par Laurent de Rauglaudre - Publié dans : Manager son projet
Ecrire un commentaire - Voir les 3 commentaires - Recommander
création de blog sur over-blog.com - Contact - C.G.U. - Rémunération en droits d'auteur - Signaler un abus