l’Art de la délégation

Le 3 août 2010 par mopertodans best practices, forum de discussion, leadership5 commentaires

Article original: The Art of Delegation de Gerard M Blair

La délégation est une compétence dont nous avons tous entendu parler – mais que peu comprennent. Elle peut être utilisée comme une excuse pour faire reposer l’échec sur les épaules de subalternes, ou comme un outil dynamique pour motiver et aider votre équipe à atteindre son plein potentiel.

« I delegate myne auctorite », Palsgrave 1530. (« Je délègue mon autorité » )

Chacun connaît la délégation. La plupart des managers en entendent parler au berceau comme des discussions d’une mère avec la baby-sitter : « appréciez simplement la télévision … voici que faire si … s’il y a un ennui m’appeler au … »; les gens ont écrit sur le sujet depuis presque un demi-millénaire; cependant, peu la comprennent vraiment.

La délégation supporte un style de management qui permet à votre personnel d’utiliser et de développer leurs compétences et connaissances pour atteindre leur plein potentiel. Sans délégation, vous n’obtiendrez pas leur entière valeur.

Comme la citation antique ci-dessus suggère, la délégation est principalement de confier votre autorité à d’autres. Cela signifie qu’ils peuvent agir et initier indépendamment; et qu’ils assument la responsabilité avec vous de certaines tâches. Si quelque chose tourne mal, vous restez responsable puisque vous êtes le manager; le truc est de déléguer d’une telle façon que les choses soient faites, mais n’aillent pas (trop) mal.

Objectif

L’objectif de délégation est de faire faire le travail par quelqu’un d’autre. Pas seulement des tâches simples consistant à lire des instructions et tourner un levier, mais aussi la prise de décisions et les changements qui dépendent de nouvelles informations. Avec la délégation, votre personnel a l’autorité pour réagir aux situations sans se référer à vous.

Si vous dites au concierge de vider les poubelles le mardi et vendredis, les poubelles seront vidées le mardi et vendredis. Si les poubelles débordent mercredi, elles seront vidées le vendredi. Si au lieu de cela vous aviez dit de vider les poubelles aussi souvent que nécessaire, le concierge déciderait combien de fois et s’adapterait aux circonstances spéciales. Vous pourriez suggérer un calendrier régulier (pour enseigner un peu de gestion de temps au concierge), mais, en laissant la décision au concierge, vous appliquerez sa connaissance locale au problème. Considérez franchement : voulez-vous être un expert dans l’action de vider la poubelle, pouvez-vous rédiger une instruction qui couvre toutes les éventualités possibles ? Sinon, déléguer-le à quelqu’un qui est payé pour cela.

Pour permettre à quelqu’un d’autre de faire le travail pour vous, vous devez assurer que :

Ils savent ce que vous voulez
Ils ont l’autorité pour le réaliser
Ils savent comment le faire.

Ceux-ci dépendent tous de la communication claire de la nature de la tâche, la mesure de leur autonomie et les sources d’informations appropriées et de connaissance.

Informations

Un tel système peut seulement fonctionner avec succès si les décideurs (votre personnel) ont l’accès complet et rapide aux informations appropriées. Cela signifie que vous devez établir un système pour permettre le flux d’informations. Cela doit au moins inclure des échanges réguliers entre votre personnel pour que chacun soit conscient de ce que font les autres. Il devrait aussi inclure des briefings par vous sur les informations que vous avez reçues dans votre rôle de manager; puisque si vous avez besoin de connaître ces informations pour faire votre travail, votre personnel aura aussi besoin de les connaître s’ils doivent faire votre (délégation de) travail pour vous.

Un des avantages principaux mis en avant pour la distribution informatisée de l’information est qu’elle facilite la dissémination rapide d’informations. Quelques protagonistes suggèrent même que de tels systèmes incitent des changements dans le partage du pouvoir de management plutôt que de simplement le supporter: que la main-d’œuvre « avec le savoir » montera, assumera le contrôle et innovera spontanément. Vous pouvez ne pas croire en cette vision, mais vous devriez comprendre ses prémisses. Si un manager limite l’accès aux informations, donc seulement il/elle est capable de prendre des décisions qui dépendent de ces informations; une fois que cet accès est ouvert à plusieurs autres, ils peuvent aussi prendre des décisions – et défier celles du manager selon des critères supplémentaires. Le manager qui craint ce défi ne déléguera jamais efficacement; le manager qui reconnaît que le personnel peut avoir une expérience et des connaissances supplémentaires (et peut ainsi améliorer le processus de prise de décision) accueillera leur apport avec bienveillance; La délégation assure que le personnel pratiquera la prise de décision et ressentira que ses avis sont bienvenus.

Contrôle efficace

Une des phobies principales de la délégation est qu’en donnant d’autres l’autorité, un manager perd le contrôle. Cela ne doit pas être le cas. Si vous apprenez à votre personnel à appliquer les mêmes critères que vous (par l’exemple et par des explications complètes) ils exerceront votre contrôle à votre place. Et puisqu’ils seront témoins de beaucoup plus de situations sur lesquelles le contrôle peut être exercé (vous n’avez pas le don d’ubiquité), le contrôle est exercé avec plus de diversité et plus rapidement que vous ne pourriez le faire. En termes d’ingénierie: si maintenir le contrôle est vraiment votre souci, alors vous devriez distribuer les mécanismes de contrôle pour permettre un traitement parallèle et autonome.

Développement progressif

Pour comprendre la délégation, vous devez vraiment penser aux personnes. La délégation ne peut pas être considérée comme une technique abstraite, elle dépend d’individus et des besoins individuels. Considérons un modeste membre du personnel qui a peu ou pas de connaissance du travail qui a besoin d’être fait.

Dites-vous « Jimmy, je veux une proposition d’offre du contrat pour la nouvelle station hydraulique sur mon bureau vendredi » ? Non. Vous dites : « Jimmy, Jennifer a eu l’habitude de préparer des offres pour moi. Passez environ une heure avec elle à revoir comment elle les a réalisées et essayez d’en compiler une pour la nouvelle station hydraulique. Elle vous aidera pour celle-ci, mais revenez me voir si elle est trop occupée avec un client. Je veux une proposition vendredi pour que je puisse la regarder avec vous » ? si possible.

La clé est de déléguer progressivement. Si vous demandez à quelqu’un de réaliser une tâche qui l’intimide, une dont il/elle ne trouve pas possible de se charger, la tâche ne sera pas faite et votre personnel sera sévèrement démotivé. Au lieu de cela vous devriez construire progressivement; d’abord une petite tâche menant à un peu de développement, puis une autre petite tâche qui construit sur la première; quand c’est réalisé, ajoutez une autre étape; et cetera. C’est la différence entre demander aux personnes d’escalader un mur nu et leur fournir un escalier. Chaque tâche déléguée devrait avoir assez de complexité pour challenger ce membre du personnel – mais seulement un peu.

Jimmy doit se sentir confiant. Il doit réellement croire qu’il sera capable de réaliser la tâche que l’on lui a assignée. Cela signifie qu’il doit avoir une connaissance suffisante, ou il doit savoir où l’acquérir ou bien où obtenir l’aide. Ainsi, vous devez permettre l’accès à la connaissance nécessaire. Si vous êtes le détenteur de cette connaissance, assurez-vous que Jimmy trouve possible de venir vous voir; si quelqu’un d’autre détient la connaissance, assurez-vous qu’ils sont prêts à recevoir Jimmy. C’est seulement si Jimmy est sûr que le support est disponible, qu’il se sentira assez confiant pour entreprendre un nouveau travail.

Vous devez vous sentir confiant en Jimmy : cela signifie le surveiller du coin de l’œil. Il serait fatal de jeter Jimmy à la mer et de s’attendre à ce qu’il rejoigne le rivage : surveillez-le avec une bouée de sauvetage à portée de main. C’est aussi une erreur d’aller voir Jimmy à des moments impromptus et lui demander des comptes rendus : il se sentira vite persécuté. Au lieu de cela vous devez être d’accord à l’avance sur combien de fois et quand vous avez en réalité besoin d’informations et décidez du planning de rapport en l’établissant dès le début. Jimmy s’attendra alors à ces rencontres et se sentira même encouragé par votre support continu; vous serez capables de vérifier le progrès et le stimulerez même un peu.

Quand vous parlez à Jimmy du projet, vous devriez éviter de prendre des décisions dont Jimmy est lui-même capable. L’idée même est pour Jimmy d’apprendre à prendre en charge et donc il doit être encouragé à le faire. Bien sûr, avec vous disponible pour vérifier ses décisions, Jimmy se sentira plus libre de le faire. Si Jimmy a tort – le lui dire et expliquer très soigneusement pourquoi. Si Jimmy est presque parfait – le féliciter et suggérer des modifications possibles; mais, bien sûr, laisser Jimmy décider. Finalement, à moins que votre solution n’ait des mérites significatifs sur celle de Jimmy, prendre la sienne : cela vous coûte peu, tout en le récompensant beaucoup.

Disponibilité Contrainte

Il y a un danger avec « la disponibilité permanente » que vous deveniez trop impliqués dans la tâche que vous aviez espéré déléguer. Une stratégie fructueuse pour l’éviter est de formaliser la façon dont ces conversations ont lieu. Le formalisme doit autoriser seulement des rencontres fixes, régulières (à part des cas d’urgence) pour que Jimmy soit obligé de penser aux problèmes et questions avant de vous les élever; vous pourriez même insister pour qu’il y ait une proposition d’ordre du jour. Un deuxième formalisme est de refuser de prendre une décision à moins que Jimmy ne vous ait fourni un exposé clair des alternatives, le pour et le contre et sa recommandation. C’est mon favori. Il permet à Jimmy de s’entrainer à la pleine autorité de prise de décisions tout en étant sécurisé de savoir que vous serez là pour en vérifier le résultat. De plus, l’insistance sur l’évaluation d’alternatives promeut les bonnes pratiques de prise de décisions. Si Jimmy a raison, sa confiance augmente – si vous n’êtes pas d’accord avec Jimmy, il apprend quelque chose de nouveau (si vous expliquez vos critères) et ainsi augmente ses connaissances. Quelque soit le résultat, il en tire bénéfice; et l’analyse est réalisée pour vous.

Résultats et Échecs

Laissez-nous considérer vos standards sans aucun doute élevés. Quand vous déléguez un travail, la personne n’a pas à le faire aussi bien que vous pourriez le faire (dans les délais impartis), mais seulement le faire aussi bien que nécessaire : ne jugez jamais le résultat par ce que vous vous attendriez à faire (il est difficile d’être objectif sur ceci), mais plutôt par l’aptitude à atteindre l’objectif. Quand vous déléguez une tâche, mettez vous d’accord sur les critères et les standards selon lesquels on jugera du résultat.

Vous devez permettre l’échec. Avec le contrôle approprié, vous devriez être capables de rattraper les erreurs avant qu’elles ne soient catastrophiques; sinon, l’échec est le vôtre. Vous êtes le manager, vous avez décidé que Jimmy pourrait s’en charger, vous lui avez donné assez de corde pour se pendre, vous êtes en faute. Maintenant que ceci est clair, laissez-nous retourner à Jimmy. Supposons que Jimmy fasse mal quelque chose; que voulez-vous qu’il advienne ?

Premièrement, vous voulez que ce soir réparé. Puisque Jimmy a fait l’erreur, il est probable qu’il aura besoin d’un certain apport pour développer une solution : donc Jimmy doit se sentir en confiance pour vous approcher avec le problème. Donc, vous devez traiter principalement avec la solution plutôt que la cause (regarder devant, pas en arrière). Le résultat le plus souhaitable est que Jimmy fournisse lui-même la solution.

Une fois que ceci est fait, vous pouvez analyser la cause. N’esquivez pas le problème; si Jimmy a mal fait quelque chose, dites le, mais seulement en des termes très spécifiques. Évitez des attaques générales sur ses parents : « êtes-vous né aussi stupide ? » Et observez l’événement réel ou la circonstance qui a mené à l’erreur : « vous n’avez pas tenu compte de X dans votre décision ». Vos objectifs sont de vous assurer que Jimmy :

Comprend le problème
Se sent assez confiant pour reprendre
Met en œuvre une procédure pour empêcher que cela se reproduise.

L’éthos le plus sûr à cultiver est celui où dans les faits Jimmy recherche et anticipe les erreurs. Si vous voulez promouvoir un tel comportement, vous devriez toujours remercier Jimmy de son action prompte et avisée à découvrir et traiter les erreurs plutôt que le punir de les causer. Ici l’accent est placé sur la vérification/test/contrôle d’idées. Ainsi vous ne critiquez jamais Jimmy de trouver une erreur, seulement de ne pas avoir des protections en place.

Que déléguer

Il y a toujours la question de ce que vous déléguer et ce que vous devez faire et vous devez prendre une vue à long terme : vous voulez déléguer autant que possible pour développer le personnel afin qu’il soit aussi bon que vous l’êtes actuellement.

Le point de départ est de considérer les activités que vous avez eues l’habitude de faire avant que vous ne soyez promu. Vous avez eu l’habitude de les réaliser quand vous étiez plus juniors, donc quelqu’un de junior peut maintenant les faire. Les tâches dans lesquelles vous avez l’expérience sont les plus faciles pour vous à expliquer à d’autres et ainsi leur apprendre à les reprendre. Vous utilisez ainsi votre expérience pour vous assurer que la tâche est réussie, plutôt qu’exécuter la tâche vous-même. De cette façon vous gagnez du temps pour vos autres devoirs et quelqu’un d’autre devient aussi bon que vous l’étiez autrefois (augmentant la force du groupe).

Les tâches dans lesquelles votre personnel a davantage d’expérience doivent leur être déléguées. Cela ne signifie pas que vous abandonnez la responsabilité parce qu’ils sont experts, mais cela signifie vraiment que la décision par défaut devrait être la leur. Néanmoins, pour être un bon manager, vous devriez vous assurer qu’ils passent un certain temps à expliquer ces décisions pour que vous compreniez leurs critères.

Les décisions sont une fonction normale de management : celles-ci devraient aussi être déléguées – particulièrement si elles sont importantes pour le personnel. En pratique, vous devrez établir les limites de ces décisions pour que vous puissiez vivre avec le résultat, mais cela vous prendra seulement un peu de temps quand la délégation du reste de la tâche vous en fera gagner beaucoup plus.

En termes de motivation pour votre personnel, vous devriez distribuer les tâches les plus banales aussi égalitairement que possible; et distribuez les plus passionnantes tout aussi largement. En général, mais particulièrement avec les tâches ennuyeuses, vous devriez être prudents de déléguer non seulement la performance de la tâche, mais aussi sa propriété. La délégation de tâche, plutôt que l’attribution de tâche, permet l’innovation. Le point que vous devez faire comprendre consiste en ce que la tâche peut être changée, développée, améliorée, si nécessaire ou désirable. Donc quelqu’un qui collationne les résultats chiffrés mensuels ne devrait pas se sentir obligé de les saisir aveuglément chaque premier lundi; mais devrait se sentir autorisé présenter un format de rapport plus efficace, utiliser un logiciel pour améliorer le traitement de données, suggérer et mettre en œuvre des changements à cette tâche lui-même.

Négociation

Puisque la délégation est de donner de l’autorité, vous ne pouvez pas dicter ce qui est délégué, ni comment cette délégation doit être gérée. Pour contrôler la délégation, vous devez établir au début la tâche elle-même, le calendrier prévisionnel de reporting, les sources d’informations, votre disponibilité et les critères de succès. Ceux-ci doivent être négociés avec votre personnel : c’est seulement en obtenant tant leur avis que leur accord que vous pouvez espérer parvenir à une procédure réalisable.

Quand tout est fait pour vous

Une fois que vous avez tout délégué, que faites-vous?

Vous devez toujours contrôler les tâches vous avez délégué et poursuivre le développement de votre personnel pour les aider à bien exercer leur autorité.

Il y a les fonctions de management que vous ne devriez jamais déléguer – celles-ci sont celles liées au personnel qui sont souvent les ajouts les plus évidents à vos responsabilités quand vous assumez un rôle de manager. Spécifiquement, ils incluent : motivation, formation, construction d’équipe, organisation, félicitations, réprimandes, revues de performance, promotion.

En tant que manager, vous avez la responsabilité de représenter et développer l’efficacité de votre groupe dans la société; ce sont des tâches que vous pouvez approfondir pour utiliser votre temps disponible – la délégation est un mécanisme qui permet de créer cette opportunité.

en complément aux leçons apprises…

Le 29 juillet 2010 par mopertodans best practices, forum de discussionLaisser un commentaire

Le billet « Road Map to Success Starts with Lessons Learned » de Lynn Wendt, PMP, PgMP nous rappelle qu’il y a de nombreuses manières d’identifier les pièges auxquels votre projet risque d’être confronté, même si votre société n’a pas de réelle base de données des leçons apprises qui mette en évidence les problèmes et leurs solutions.

Vous pourriez envisager une ou plusieurs des approches suivantes pour maximiser vos chances de réussite.

1. Demander un mentor. Demandez à votre patron de suggérer un mentor. C’est une bonne façon de partager des informations et de développer des relations durables dans une société.

2. Trouver les informations telles que les registres de risque et de problèmes sur des projets semblables de votre organisation. N’oubliez pas que ces registres pourraient ne pas être formellement organisés ou archivés, utilisez votre réseau pour les dénicher.

3. Prendre connaissance des benchmarks de consultants externes et/ou d’organisations professionnelles. Il y a beaucoup d’informations sur Internet fournies par des pros ou des organisations professionnelles.

4. Interviewer des dirigeants sur leurs perspectives de pièges potentiels pour votre projet. Vous y gagnerez des avis de valeur et montrerez que vous êtes un joueur d’équipe préoccupé de bien comprendre les objectifs de la société.

5. Demander à votre équipe ce qui s’est déroulé bien ou pas si bien sur d’autres projets sur lesquels ils ont travaillé. C’est un bon exercice de construction d’équipe que les membres regardent ensemble les pièges potentiels et les solutions.

6. Rencontrer de façon informelle d’autres chefs de projet. C’est une bonne manière d’enrichir son réseau et d’échanger des idées pour s’entraider. Vous pourriez les rencontrer dans votre organisation, sur internet ou dans des rencontres de votre chapitre PMI local.

7. Écouter le folklore de la société sur les projets passés. Vous pourriez y recueillir des informations de valeur sur la culture de l’organisation.

Après avoir réussi votre projet, rappelez-vous de partager ce que vous avez appris, par le processus formel si il existe ou de façon informelle en prenant à votre tour un rôle de mentor pour d’autres chefs de projet.

best practice or not?

Le 23 juillet 2010 par mopertodans best practices, forum de discussionLaisser un commentaire

As this blog is about best practices and improving our skills in project management, I found the article « what is best practice? » by Ted Hardy quite relevant.

In fact, the real question may not be to determine if a practice is good, bad or best. A more appropriate question is: « Is the practice appropriate for me, my company, and my project? »

Or one could ask: « How does it fit me? »

Indeed, Ted reminds us that applying a « best practice » has never been a guarantee for success. However, it can help you to unlock a difficult situation. It is also very useful to position yourself, to benchmark against peers and competitors. It also may help you understand why some have succeeded where you are in trouble. Additionally, it is worth keeping in mind that best practices are not set in stone, they too need to evolve. And, it is not because you have applied a best practice once or a few times that you have truly acquired it.

So, what criteria may we use to identify for sure best practices?

Well… may be can we use an approach similar to the one often used to distinguish good from bad objectives, they need to be S.M.A.R.T. Here are my proposals for what S.M.A.R.T. may be for « best practices »:

S-pecific: What exactly is this best practice for? In what context shall it be used? It should be applied in order to reach what precise objective?

M-easurable: How will I know if it works or not? How will I know that I have implemented the Best Practice in a correct manner? How will I be able to benchmark against others who use it?

A-daptable: It needs to fit my project, my business context, my specific constraints…

R-epeatable: How may I be sure that, when applied, it will consistently provide the same efficient results? Also, as written above, I will need to apply it several times before being in position to say that I master it.

T-ested: I need to be in position to give it a good try, to prove it can work in my environment, and on my project before it can be adopted at a wider scale in my company.

meilleure pratique ou pas ?

Le 23 juillet 201023 juillet 2010 par mopertodans best practices, forum de discussionLaisser un commentaire

Comme ce blog est centré très précisément sur les meilleures pratiques et l’amélioration de nos compétences en management de projet, j’ai trouvé l’article « what is best practice? » de Ted Hardy fort à propos.

En fait, la vraie question pourrait bien ne pas être de déterminer si une pratique est bonne, mauvaise ou meilleure. Une question plus adaptée serait : « est-ce que cette bonne pratique est appropriée pour moi, ma société, mon projet ? ». En d’autres termes: « comment me va-t-elle? »

En effet, Ted nous rappelle qu’appliquer une « meilleure pratique » n’a jamais été une garantie de succès. Cependant, cela peut nous aider à débloquer une situation difficile. C’est aussi très utile pour se positionner, s’évaluer par rapport à ses pairs et ses concurrents. Cela peut aussi aider à comprendre pourquoi certains ont réussi là où vous rencontrez de sérieux problèmes. De plus, il faut garder à l’esprit que les meilleures pratiques ne sont pas gravées dans le marbre, elles devront évoluer. Et puis, ce n’est pas parce que vous avez appliqué une meilleure pratique une fois ou même à plusieurs reprises qu’elle est vraiment acquise.

Quels critères pouvons-nous utiliser pour identifier à coup sûr les meilleures pratiques ?

Eh bien … peut être pourrions-nous utiliser une approche semblable à celle souvent utilisée pour distinguer les bons des mauvais objectifs, ils se doivent d’être S.M.A.R.T. Voici mes propositions sur ce que S.M.A.R.T. pourrait être dans le cas des « meilleures pratiques » :

S-pécifique : Une meilleure pratique pour quoi exactement ? Dans quel contexte peut-elle être utilisée ? Elle devrait être appliquée pour atteindre quel objectif précis ?

M-esurable : Comment saurai-je si elle fonctionne ou pas ? Comment saurai-je si j’ai vraiment mis en œuvre la « meilleure pratique » correctement ? Comment serai-je capable de me comparer à d’autres qui l’utilisent ?

A-daptable : Elle doit convenir à mon projet, à mon contexte business, à mes contraintes spécifiques …

R-épétable : Comment être certain que lorsqu’elle est appliquée, elle fournit systématiquement la même efficacité de résultat ? Comme exposé ci-dessus, je devrai probablement l’appliquer plusieurs fois avant d’être en position de dire que je la maîtrise.

T-estée : Est le qualificatif qui me vient à l’esprit. Je dois être me mettre en position de lui donner une vraie chance, de prouver qu’elle peut marcher dans mon environnement et sur mon projet avant qu’elle ne puisse être adoptée plus largement dans mon entreprise. Donc, il faut descendre dans les tranchées avec cette meilleure pratique pour prouver qu’elle résiste au feu.

Amélioration de la Communication dans les Projets : Deux règles dont vous n’avez probablement jamais entendu parler

Le 18 juin 2010 par mopertodans best practices, forum de discussionLaisser un commentaire

Un nouvel article intriguant de Ty Kiisel: « Improving Project Communication: Two Rules You’ve Probably Never Heard Of »

Bien qu’Alexandre Graham Bell ait considéré son invention la plus célèbre, le téléphone, comme une intrusion dans son vrai travail de scientifique, je ne pense pas que vous trouveriez énormément de personnes aujourd’hui qui seraient enclines à renoncer à leur téléphone mobile.

Nous vivons dans un monde de communication instantanée. Des téléphones mobiles, Internet, SMS, médias sociaux — tous nous maintiennent connectés et communicant, n’est-ce pas ?

Il y a des moments où j’ai la sensation que la technologie a rendu la communication plus accessible, mais qu’elle n’a pas vraiment rendu la communication plus facile. Pour que la communication de projet soit efficace, nous devons réfléchir sur comment nous utilisons la technologie. Il est important de se rappeler que nous pouvons écrire un courrier électronique ou mettre à jour un rapport, mais que la personne à l’autre bout de ce courrier électronique ou lisant le rapport est une personne. C’est probablement simplement la nature de la technologie, mais parfois je pense que c’est une bonne idée de se rappeler ce qui fait que la communication efficace, est efficace.

Voici deux ou trois techniques qui ne viennent pas de moi, mais pourraient vous aider à améliorer la qualité de votre communication de projet :

La Règle du Coucher du soleil :

À moins que vous ne travailliez chez Walmart, vous n’en avez jamais probablement entendu parler. Selon leur Site Intranet d’entreprise: C’est seulement une version du ‘pourquoi remettre jusqu’à demain ce que vous pouvez faire le jour même ?’

L’observation de la Règle du Coucher du soleil est très simple. Que ce soit une requête d’un magasin dans le pays ou un appel d’un collègue au bout du couloir, nous donnons notre meilleur pour fournir le service à nos clients et entre nous, le jour même. »

Je travaille avec un collègue qui a fait un internat d’université à Bentonville, AK, au siège social de Walmart. Il a dit que la Règle du Coucher du soleil est une réalité. Peu importe qui il a appelé dans la journée, il obtient typiquement une réponse avant le coucher du soleil.

Traiteriez-vous le courrier électronique ou toute autre correspondance de projet avec vos membres d’équipe projet un peu différemment si vous saviez que cela implique une réponse avant la fin du jour ?

Vendredis sans courrier électronique:

J’ai entendu parler du « Aucun Courrier électronique le Vendredi » de U.S. Cellular il y a deux ou trois ans. Le COO, Jay Ellison, a pensé qu’il rendrait la vie un peu plus facile et allégerait la charge de travail des salariés, mais au lieu de cela, il a initialement causé un incendie dévastateur.

Dans un article écrit par Sue Shellenbarger dans Le « Wall Street Journal », elle cite Kathy Volpi, une directrice commerciale qui a dit: « j’ai pensé, ‘ Il ne comprend tout simplement pas combien de travail nous devons abattre et combien c’est plus facile en utilisant le courrier électronique.' »

À l’exception des réponses aux questions urgentes, on considère tout autre courrier électronique normal comme étant tabou. L’initiative a été conçue pour encourager la communication en face à face avec les clients et les collaborateurs, accroître la productivité, ou fournir une pause par rapport à la boîte d’arrivée de courrier électronique qui se remplit tout le temps.

Il semble que cela ait été un succès.

Même Mme Volpi, maintenant directrice chez U.S. Cellular du management de produit et du marketing, est devenue une supportrice. Selon Shellenbarger, « Progressivement, elle s’est rendue compte que lire et répondre à tout le courrier électronique qu’elle envoyait étaient probablement un fardeau pour ses collaborateurs. Maintenant, elle ne manque pas de rendre visite à ses collaborateurs le vendredi. Le Business, dit-elle, n’est pas seulement l’envoi de courriers électroniques ‘contenant des rapports froids’ et efficaces, elle dit, ‘ C’est à propos de personnes et d’interactions’. ‘ »

Ces techniques marcheraient-elles dans votre organisation ? Je ne sais pas. Il y a tant de fonctionnalités de collaboration de communication incorporées dans beaucoup de solutions de management de projet traditionnelles ou en ligne qu’éliminer complétement ce type de communication pourraient être problématique. Cependant, indépendamment du logiciel de management de projet ou les outils de gestion du travail que vous utilisez, chacun peut sortir de son bureau/cube pendant quelques minutes et avoir une conversation réelle de temps en temps.

Je dois admettre que parfois c’est plus facile pour moi de contacter un collègue à 3 mètres de distance par un Message Instantané que de me lever de ma chaise et d’aller lui parler directement. Je me demande combien de nous ont oublié comment vraiment parler entre personnes quand IM, SMS et courriers électroniques dirigent notre vie ?

Donnez une chance à ces deux approches et voyez si elles marchent pour vous et votre équipe projet. Vous pourriez être étonnés de l’évolution de l’efficacité de votre communication quotidienne quand vous incorporez un peu de discussions en face à face de temps à autre.

une bonne préparation permet de réaliser de meilleures présentations dans les conférences

Le 27 Mai 20101 juillet 2010 par mopertodans best practices, forum de discussion5 commentaires

Tout comme l’auteur du billet « Preparing to present at conferences », j’ai passé de nombreuses heures à regarder la nuque de présentateurs tandis qu’ils lisaient les points mentionnés sur leurs transparents projetés sur l’écran derrière eux.

En fait, je reconnais avoir commis cette erreur moi-même de nombreuses fois. Et, je ne pense pas avoir à en rougir. Personne ne m’avait appris dans notre système éducatif français de l’époque à réaliser des présentations, à prendre la parole en public et à transmettre des messages par ce moyen de communication. Cela a heureusement bien changé comme j’ai pu le constater avec mes filles et neveux qui ont l’opportunité dans leurs études supérieures de réaliser de nombreux travaux individuels et de groupe qui sont ensuite présentés à l’oral avec le support de transparents.

Bien que certainement moins expérimenté en la matière que l’auteur du billet mentionné ci-dessus, voici quelques points que personnellement je m’efforce de respecter:

Savoir exactement le message que j’aimerais que l’assistance retienne de la présentation. Ce que j’aimerais les voir faire ou changer suite à ma présentation.
Prendre le temps nécessaire à la préparation de la présentation. Même sur un sujet bien maîtrisé, il est important de bien préparer l’intervention, de bien analyser l’audience et l’objectif à atteindre, ainsi que les conditions physiques et matérielles de la présentation. Pour se faire, j’ai récemment réappris à ne pas me jeter sur Powerpoint d’entrée de jeu. Je commence par écrire sur papier ou sur tableau blanc le scenario, la trame de l’histoire que je souhaite raconter, la structure du propos, avant de réfléchir à comment le transmettre au mieux sous forme de transparents Powerpoint.
Éviter les transparents encombrés. La présentation n’est qu’un support au discours. Elle doit permettre à l’audience de mieux mémoriser certains éléments, en particulier grâce à des images et des illustrations frappantes. Dans le cas d’une présentation en personne face à une large audience, il n’est pas question de lire une liste de lignes de texte. Il faut transmettre une émotion, un message, une histoire que l’audience retiendra facilement et sur laquelle elle agira ensuite. Une présentation effective est une présentation dont on verra les effets comme le dirait encore aujourd’hui mon professeur de « Effective Meetings and Presentation Skills ».
Répéter, répéter, répéter… Le jour J, le discours doit être fluide. Aucune nécessité de lire les transparents pendant la présentation, ils ne sont qu’une illustration d’un discours que vous maîtrisez de A à Z. Vous avez également préparé des anecdotes et références à votre expérience personnelle pour donner vie aux points que vous allez aborder. Vous avez également essayé d’anticiper au mieux les questions, qui à les susciter vous-même si elles ne viennent pas spontanément.
Repérez la salle et les conditions matérielles de l’intervention à l’avance. Quel type de micro par exemple: statique (à bannir), micro-cravate, micro mobile. Cela va influencer, voire limiter votre capacité de mouvement. Il vaut mieux le savoir à l’avance. Défilement des transparents: commande à distance, opérateur (il faudra le préparer à l’avance), nécessité de retourner au PC pour passer au transparent suivant… Cela va influencer la dynamique de vos transparents et l’affichage progressif des transparents par exemple.
Si vous voulez utiliser du son ou de la vidéo pendant la présentation (une bonne idée qui dynamise les longues sessions), assurez-vous qu’ils passent bien dans la salle, au plan visuel et acoustique, et ce, même depuis le fond de la salle.
Préparer un papier d’accompagnement de la présentation au format Word, Acrobat ou un article sur le web, est une bonne idée. Signalez que ce document existe et où le trouver à l’audience en début de votre présentation pour qu’elle se focalise sur l’écoute de ce que vous avez à dire plutôt que d’essayer de tout noter.
Faire des recherches sur l’assistance ainsi que l’organisation qui vous donne l’opportunité de vous exprimer.
Fournir son pack de transparents à l’avance est également une bonne idée même si cela n’est pas expressément exigé par l’organisateur. Cela vous force à être prêt à 100% bien avant l’événement. A la relecture, quelques jours avant l’intervention, vous pourrez simplement revoir les exemples que vous comptez utiliser et les histoires à raconter en fonction de l’actualité du moment.
Prévoir un verre d’eau accessible pendant la présentation. Cela permet d’éviter d’avoir la gorge sèche et cela permet aussi de se poser quelques secondes pour réfléchir en cours de présentation.
Ne dépasser son temps de parole sous aucun prétexte est ma devise, en particulier si il y a d’autres présentateurs qui suivent.

Qu’ajouteriez-vous à ce début de liste ?

les secrets pour réussir une externalisation selon Prince2

Le 28 avril 20104 Mai 2011 par mopertodans best practices1 commentaire

Ces articles sur l’externalisation ou « outsourcing » m’ont paru intéressant car c’est un sujet peu souvent abordé auquel j’aimerais ajouter quelques commentaires basés sur mon expérience personnelle acquise lors de l’externalisation de l’informatique et du réseau interne d’un grand équimentier télécom dans les années 2000.

Secrets to Successful Outsourcing – Part 1 & Part 2

Quels sont les facteurs critiques à une opération d’externalisation et des partenariats d’externalisation réussis Que ce soit pour des tâches simples ou d’énormes projets?

1. Préparation : On ne devrait pas voir l’externalisation comme la panacée instantanée à tous les maux opérationnels, financiers ou autres d’une société. Avant de nouer des liens avec un associé d’externalisation éligible, la société cliente doit entreprendre un processus décisionnel complexe. Les approches comme PRINCE2 et Managing Successful Programmes peuvent être utiles dans la décision de partir vers l’externalisation ou pas, de manager efficacement un projet externalisé, et cetera.

2. Savoir-faire / compétence cœur de business : En règle générale, cela a du sens pour une société que d’externaliser des tâches répétitives ou spécialisées tout en conservant les fonctions fondamentales qui sont centrales et uniques à son business. Le calcul de la corrélation entre la capacité d’achever une tâche avec succès et sa valeur business peut aider à déterminer les secteurs qui devraient rester internes et ceux qui devraient être sous-traités.

3. Bonne gouvernance : On pourrait dire de l’établissement d’une structure de gouvernance et d’une équipe de direction expérimentée avec un comité de direction de projet que ce sont les pierres angulaires d’une externalisation réussie. La structure pourrait inclure, entre autres choses, le contrat et des processus d’exécution et apportera clarté et cohérence pour le fournisseur et le client.

4. Parties prenantes : Encourager l’implication et trouver la bonne balance entre les besoins de toutes les parties prenantes serait intelligent pour les garder à bord, tout particulièrement quand les parties prenantes incluent les investisseurs ou les actionnaires.

5. Buts et Objectifs : Déterminez quels besoins doivent être réalisés par l’externalisation et partagez avec tous les participants. Rappelez-vous qu’une tension commerciale normale qui existe entre un client et un fournisseur peut signifier que leurs buts et objectifs peuvent ne pas coïncider. Les clients veulent normalement payer le prix le plus bas possible pour la meilleure qualité; les vendeurs veulent normalement maximiser le revenu et minimiser des dépenses.

6. Compatibilité : les clients et les fournisseurs qui ont quelque chose en commun ont naturellement plus de probabilité de rester ensemble. Les différences en expertise, méthodologies, éthos, valeurs, pratiques de travail, langue et cultures : celles-ci sont certaines des choses à considérer pour établir s’il y a une bonne adéquation entre les deux parties. Par exemple, si un client et un vendeur utilisent la même approche – comme PRINCE2 – ils peuvent être sûrs sans tenir compte du composant qu’ils achèvent, qu’il se raccordera avec les autres parties du projet.

7. Processus de sélection de Fournisseur : l’Évaluation inclurait : le coût total, les bénéfices attendus, la stabilité financière, la capacité, la compétence, la fiabilité, les processus d’audit, le contrôle qualité, la localisation géographique et la taille, en classant les prétendants potentiels par rapport à ceux-ci. Cela vaut la peine de noter bien sûr que le fournisseur le plus bon marché n’est pas nécessairement le meilleur puisqu’il peut avoir conservé une trop faible marge d’erreur qui peut mener à des dépenses plus élevées, qui pourraient à leur tour être passées aux clients. Les accords de Niveau de Service, des Indicateurs Clefs d’Exécution et d’évaluation de performance jouent naturellement leur rôle à divers moments dans la vie du contrat d’externalisation.

8. Options d’Approvisionnement : En adoptant une approche flexible d’approvisionnement, les sociétés peuvent adapter la stratégie d’approvisionnement aux projets, aux services et aux circonstances. Une situation économique fragile peut faire paraître le multifournisseurs plus attractif que le fournisseur unique pour répartir le risque d’externalisation sur plusieurs fournisseurs; cependant, les risques tels que la perte possible d’intégration au travers de multiples projets et une pauvre gouvernance peuvent rendre cette option périlleuse. L’externalisation « intéressée » où clients et fournisseurs collaborent pour réaliser ensemble leurs buts et objectifs est une approche qui peut valoir la peine d’être examinée.

9. Contrats : un contrat solide est essentiel et les sociétés peuvent y couvrir un grand nombre de choses comme les rôles, les responsabilités, les garanties, les niveaux de service minimaux, les bonus, les pénalités, la propriété des données, les droits de propriété intellectuelle, etc. Intégrez de la flexibilité pour pouvoir faire les changements qui seraient nécessaires sur des projets à long terme et cela peut inclure l’option de poursuivre un Plan B ou de mettre en œuvre une stratégie de sortie de contrat. Finalement, considérez la possibilité de découper les grands projets ou grands contrats en de plus petits.

10. Transition : Formez une équipe des deux côtés de l’association pour gérer la transition, définissez les processus à suivre, définissez une ligne de temps et établissez les points de rencontres ou jalons qui matérialisent l’achèvement de chaque partie du processus de transition.

11. Communication : au cœur de toute externalisation réussie est la façon dont les sociétés sont connectées l’une avec l’autre et avec leurs parties prenantes, donc de bons canaux de communication sont essentiels. De bonnes relations client/fournisseur peuvent aider chaque côté à clarifier et comprendre les buts, rôles, responsabilités, progression du projet, développements de l’industrie, changements business et autres et peuvent en conséquence aider à créer la confiance entre toutes les parties.

12. Le Personnel Clef : Pour mieux contrôler vos projets d’externalisation, le personnel compétent clef pour contrôler la performance d’exécution de la société prestataire et prendre ces décisions clefs de management. Le moral du personnel peut aussi être accru par leur acquisition d’expertise du fournisseur pendant le processus d’externalisation qui peut à son tour permettre à la société de retenir les personnels clefs et les conserver plutôt que les externaliser sur des projets semblables à l’avenir.

13. Mesure de Résultats: une gamme de mesures rigoureuses mais significatives qui ne comptent pas excessivement sur des outils comme les Accords de Niveau de Service (Service Level Agreements: SLAs) ou des Indicateurs de Performance Clefs (Key Performance Indicators: KPIs), mais qui intègrent des évaluations qualitatives peuvent efficacement contrôler la performance du projet d’externalisation et voir s’il délivre ce que l’on a promis.

14. Risques : Toute relation apporte des risques et ils peuvent être coûteux : les projets peuvent être retardés ou échouer, les réputations peuvent être ternies, les données peuvent être perdues, la sécurité peut être contrevenue et bien plus de désastres dans la même veine pourraient atteindre de la même façon le fournisseur et le client. Les sociétés peuvent adopter des mesures comme des registres de risque et adopter des approches, telle que le Management des Risques, pour les aider à réduire leur exposition aux désastres potentiels.

15. Sécurité : l’accès aux données est un sujet sensible et la protection des données une priorité. Les clients doivent donc considérer leur responsabilité conformément aux lois de protection des données et s’assurer que les fournisseurs ont le stockage de données adéquat, le chiffrage, des coupe-feux(firewalls) et détection de fraudes et semblables.

APMG France bannière — Partenaire de DantotsuPM

10 false ideas about Agile Methods

Le 22 avril 2010 par mopertodans agile, best practices, outils et méthodesLaisser un commentaire

For once, I decided to translate French articles for our English speaking readers and those of us based in France who work in an international context and would like to share these with our foreign colleagues.

The original articles (2 posts in fact) were published by Renaud Choné on the blog of his company, Time Performance: http://www.timeperformance.com/blog/16-generalites/101-5-idees-fausses-a-propos-des-methodes-agiles

The wide variety of agile methods and their practices generates numerous false ideas on this subject. The object of this article is to demystify the most common false ideas found in the debates on Web by answering these factually.

The arrival of the Agile Methods is generating a ditch between their partisans and those of traditional methods. This rupture is strengthened by the fact that 4 founding principles of the agile methods contradict directly the classic approach:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

( Cf. the Agile Manifesto, the official site: Http://agilemanifesto.org/)

The idea here is not to take position but to allow healthy debates. Indeed, at Time Performance, we are convinced that there is no good method for every situation. And it is moreover why our management of software projects was designed to be flexible while being inspired by the best practices and tools, agile or classic.

False Idea n°1: the Agile Methods apply only to « small » projects

False, forgery and ultra-false… It is nevertheless the most wide-spread idea. It is also the most false.

1) The reason for being of Agile Methods is to allow the project to adapt itself easily to the changes ( » Reponding to changes « ). It makes sense only for the projects of rather long duration, because the risk of change is strong all the more as the project goes on. Furthermore, the duration is necessary to take the full benefits of the heavy investments made in the tests, their automation and the quality of the code, which are at the heart of the agile methods.

Moreover the Agile methods were designed for the development of software products (hence the term of Product Owner which we find in SCRUM), for which the life cycle extends over several years or even several decades.

This false idea was maybe inspired by the brevity of the development cycles. And precisely, an iterative development aims at avoiding the risk of tunnel effect, which is important all the more as the project is long.

Thus the Agile methods are particularly adapted, even recommended, for long projects and not for the small ones.

2) Concerning the size of the team, it is true that SCRUM limits the size of the teams to 8 or 9 individuals, and XP recommends it in practice, because it is the optimal functioning. But nothing forbids establishing several teams which will work each on a sub-project. Moreover SCRUM embeds it with a coordination mechanism which is called the SCRUM of SCRUMs. A team of several dozens of persons can be so constituted.

False Idea n°2: the classification « Agile Method » determines a homogeneous group

The Agile methods are very different from one to another. They are even sometimes almost totally complementary, as XP and SCRUM. If these last 2 methods mark a real break with regard to the classic approach, some as Unified Process establish intermediate steps in the evolution of the methods during the last 20 years.

All these methods agree only on the 4 principles, that is little. Furthermore, the Agile Manifesto offers certain freedom in interpretation. It is thus risky to speak about Agile Methods generally. It is better to speak about practices proposed by such or such method.

On top, it is necessary to add that the implementations of these methods are even more heterogeneous.

False Idea n°3: the Agile Methods are methods of project management

Firstly, the object of the agile methods is software development and not the management of projects. If certain topics of project management are mentioned such as the estimates and the planning, others are plainly absent (for example costs management).

Secondly, the agile methods are not methods. The authors of XP and SCRUM define them as sets of good practices.

False Idea n°4: the Agile Methods are methods of rapid development or prototyping

Short cycles of delivery do not mean that the developments are rapid. It implies simply to validate the progress regularly and concretely.

There are even chances that the developments will be less fast at first with regard to a V cycle, because of the requirements in quality of code and tests coverage, including of numerous re-developments. It is not thus a good approach to use for prototyping.

The Agile projects are marathon runners and not short-distance runners. That is why they travel light. And on the distance, they are generally the fastest and consume less.

False Idea n°5: the agile developments are with difficult to maintain because of the lack of documentation

The fear of seeing the knowledge of the functioning of the software leaving with developers at the conclusion of the project is perfectly justifiable when the documentation is insufficient.

However it is an error to consider that there is no documentation. Following the example of Open Source, in an Agile approach, the main documentation is the source code. And as numerous deliveries are realized throughout the project, everything is made to guarantee a perfect maintainability.

On one hand, the coding rules are very strict and their validation is automated. Several practices at the heart of the Agile methods (the refactoring, the absence of Code Ownership, the Pair Programming etc.) guarantee in the end an appropriate, well designed, legible and well documented source code.

On the other hand, in the source code it is necessary to include the tests (unit, integration, functional etc.). The tests are similar to a document of detailed specifications and an integrated validation tool. It is a significant but indispensable investment for the maintainability and the evolution.

In an agile approach, the source code and the tests stand for respectively detailed design and detailed specification, expressed in natural language in comments and in IT language. The big advantage is to guarantee that the documentation is always up to date with regards to the code, and that the code corresponds to the specifications thanks to the daily tests execution and continuous integration. An agile development should thus be very easy to maintain.

Really, the true question is: « between a complete documentation (specification, analysis, design etc.) and an appropriate and well tested source code which would you choose? »

The agile methods give the priority to the source code and to the tests. The V cycle favors in practice the documents which are generated upstream in the project, to the detriment of the code and the tests situated downstream in the cycle when the pressure to go fast, too fast, is much stronger.

False Idea n°6: the Agile Methods, it is the freedom to do it its own way

Team in « self-management » mode, questioned project manager’s role, redistribution of the responsibilities, the abolition of the contractual aspects, no detailed planning, absence or almost of documents, mainly verbal communication…

All these elements which seduce the teams have a flavor of freedom and emancipation which will frighten more than a manager.

However it would be false to consider that the Agility is synonymic of absence of rules, constraints and structures.

The Agility is above all a change in priority, as demonstrate the 4 principles of the Agile Manifesto. With more distance, it is also a change in the nature of a project, the objectives of which are not any more the respect for a requirements book, at costs and on time.

Now all these changes rest on different organization models which have their own rules.

To be Agile, it is not enough not to apply the former rules, it is especially necessary to apply the new ones.

False Idea n°7: the Agility, it is simple thus it is easy

Following the example of a chess game, the rules of the Agility are simple but their application is not. Several years of practices are needed to master well the game.

The Agility is synonymic of lightness and simplicity. It is natural to see a promise of ease there.

This promise is confirmed by books on Agility. They are generally less thick and less heavy than their equivalents; the principles and the presented concepts are much less numerous and simpler.

To acquire the theory is thus easy, but what about the practice?

In practice, the Agile methods impose very strong requirements on the individuals and the organizations.

For the individuals, there is at first a requirement in technical skills to produce an evolutionary, quality and easy to maintain software, well tested etc. This does not apply only to the Agile methods. The difference is that it becomes a priority with the Agility.

For the individuals, there is then a requirement of behaving and personal discipline to collaborate, communicate, make a commitment, and demonstrate self discipline… It is very difficult to set up Pair Programming; and Daily Scrum can easily turn into chaos.

Some organizations would need almost reorganization. For example, to involve more the business in the development, to redefine the jobs (project manager, scrum master etc.) etc.

For organizations, there is also a problem of the lack of mid-term and long-term visibility with an impact on how projects are budgeted.

Finally, the Agility rests on a strong requirement of Transparency. It can have heavy implications for organizations and individuals. Ken Schwaber, co-author of the Scrum method, expresses with provocation a direct consequence of this transparency strengthened by fast feedbacks: » [the Agility] expose the incompetence « . Stated this way, it makes you think…

In practice, very few teams arrive at the end of an Agile step(initiative). But fortunately, the passage in the Suppleness can be gradually made with immediate gains (cf n°9).

False Idea n°8: the Agile Methods require senior developers

The requirements of Agility on the individuals (cf. N°7) lead to think that the agile methods are reserved for experimented teams, teams of champions of the development. This is exaggerated.

The minimum required by the Agility would be rather a team consisting of an experimented coach and open-minded individuals, capable of questioning, capable of learning and especially who want to progress.

With regard to other methods, an advantage of the agile methods is to facilitate the fast grow in skills of the team members.

How? Simply thanks to the very short iterative cycles which allow fast feedbacks on performance and improving for the following iteration. In SCRUM, it is institutionalized under the shape of a Retrospective at each iteration end.

Besides, practices such as the Pair Programming and the Daily Scrum facilitate largely the transmission of knowledge between the members of the project.

We can retain a principle: the less the team is experimented, the more the « Coach » owes to be.

False Idea n°9: incompatibility with the classic approaches

The agile methods propose practices which, taken separately, are not incompatible with the classic approaches (cascading cycle, CMMI, PMBoK etc.).

For example, it is possible in a cascading cycle to introduce Peer Programming, Retrospect, daily meetings, the Palnning Poker, Burndown charts, continuous integration, the Test Driven… Why not?

If there is incompatibility, it is not at the level of the practices, but rather at the level of the values.

False Idea n°10: the Agility can apply to anything and everything

When, to test its software, it was necessary to reserve several days in advance some machine processing time on the central server and print its software on punch cards, the Agility and its Test Driven and Continuous Integration would have made anyone laugh out loud

To be Agile, it is necessary to have the will but also the means.

In domains, as construction or industry *, the constraints certainly do not allow to be as agile as in the software development.

In a project at fixed price, a purely agile approach is inconceivable. It is inevitably necessary to fix the perimeter.

In a deployment project, the Agility may bring more inconveniences than advantages.

To be able to be Agile, the change has to be desirable but also possible at low-cost. That is why the software development is the privileged domain of the Agility.

* In the industry, there is a Lean Manufacturing. This approach shares some of the values and objectives of the Agility, but with different practices oriented towards the industry.

Be the Chinese doctor of your projects. Watch their vital signs.

Le 16 avril 20101 juillet 2010 par mopertodans best practices, forum de discussionLaisser un commentaire

I posted a new article on the Blog Orange Business Live.

As a Chinese doctor, who is paid to keep his clients in good health rather than to look after them when they are sick, the project manager has to follow the vital signs of his project, and to address them before it seriously gets sick.

Definition and implementation of concrete measures
Critical path
Respect for the schedule (variance of + or – 10 %)
Current efforts and results reached compared to plan
Projected costs and actual spend
Quality of the deliverables
Open Problems (number, time of resolution, age)
Periodicity of reviews
Management and control of the risks
Morale of the team and human aspects
Participation of the sponsor, involvement / satisfaction of the customer
Anticipation by the trend analysis of the indicators

Read the full article and let me know which other vital signs of projects should be watched.

why forcing unrealistic project dates is often counter productive

Le 9 mars 20101 juillet 2010 par mopertodans best practices, experience sharing, forum de discussion2 commentaires

It is not rare that project dates, in particular the end date, are forced on the project manager and his team. Are they realistic? How were they estimated and approved? What is their foundation?

Here are some ideas to better handle this somewhat frequent problem.

The arbitrary…

Let’s keep in mind the 3 parameters of projects: any project can be represented as a triangle which summits are time, costs and contents. To freeze or force one of the summits often implies sacrifices on one of the other two.

Thus, fixing a completion date in an arbitrary manner can lead the project team to try to reduce the contents (the scope) to fit the timeframe. It can also drive costs up with the use of more resources to reach by all means the time target either with more resources, or superior skills or more expensive ones due to time pressure (reduced negotiation position) or all three. Naturally, these changes should generate the necessary discussions with sponsors and stakeholders to reach an agreement. If the compulsory date is absolutely unrealistic, it is of the duty of the project manager to pull the alarm bell and even consider refusing the project (must read: « Code of Ethics and Professional Conduct » of PMI).

On the sponsors’ side, it is necessary to be capable (I would even say that it is a duty) to explain the reasons behind the forced dates. These reasons can very well be valid and the project team, once it will have integrated them, will be motivated all the more to reach them.

A real life example was the implementation of a new accounting system at a big multinational firm. The sponsor of the team dedicated the necessary time to explain to all the stakeholders, project teams, future users, and management, the necessity of a launch of the new processes and application software on January 1st. Any delay would have caused big difficulties in data conversion and reconciliation at any other time during the year, i.e. additional pain for each person… The whole company was mobilized from then on; the deployment took place in time and was a success.

Rough estimates

There are many more or less scientific estimation techniques. The most wide-spread are the analog, parametric, intuitive methods or the experts’ advice, and « Bottom-Up ». Without going into too much details in this article, by analogy is about comparing a future project to similar already realized projects and extrapolating the estimates from this base. For example, if I have already implemented a software package in country X and I have to deploy the same product in country Y which of comparable size and complexity. I consider by analogy that the cost and the timeline for country Y will be sensibly the same as country X. The parametric method focuses at a high level at defining parameters that will allow estimating duration, efforts and costs. This is often used in Information Technology with parameters such as the number of screens, lines of code, interfaces between systems, and the other « Function Points » … The intuitive method is as its name indicates based on the personal appreciation of the estimator and it is mainly used to get quickly an order of magnitude. It is particularly useful upstream to prioritize approaches and downstream to identify potential incoherencies in the results produced by more detailed methods. The experts’ advices are often used to rationalize intuitive results. The experts draw from their experience and skills to provide their best estimates. Finally, the » Bottom-Up » method, more analytical requires much more detailed work at the level the deliverables of the project to estimate efforts, duration and costs. Generally, it is implemented via the Work Breakdown Structure of the project (WBS), and we try to estimate at the lowest level possible.

The best is to apply to several methods and compare the results.

Involvement of the team and the project manager

For the project to be successful, we will need that the team understands and signs off for the dates, even if imposed, as well as the effort estimates… If we take the example of Scrum in the software industry, at the beginning of each code development iteration (the Sprint), the members of the team often have the possibility of choosing themselves in the list prioritized by the customer (« product backlog ») which they take the commitment to realize over the period. They are completely engaged from then on with the task and the duration.

At minimum, the project manager must be able to be confident that he dates can be held in order to motivate his team on the duration, contents and quality.

Realistic and reachable plans

Realists for whom? First of all for the project team. As mentioned above, the project manager and his team are going to have to answer in a positive way the following questions: Will we succeed in delivering a product or a service that we we will be proud of in the allotted time? What sacrifices will it require and are we ready for these? Will we get the necessary support from our sponsors?

Maintaining a completion date in spite of the delays to start

This case is regrettably very frequent. The supplied estimates are correct and the end of September was reachable with January 1st start of the project. But, here we are, on March 9, and over the past three months sponsors and stakeholders hesitated, asked additional questions, did not manage to find time slots to meet… Finally, they saw each other this morning and agreed: we have the green light, this is great news! And (not as good) we are asked to respect the end of September completion and the budget!!! It will sound familiar to you, I am quite sure. However, unless we had inflated extravagantly our estimates (by 30 %) or are able to cut into the deliverables/contents, it will be mission impossible. Increasing the number of resources in such a drastic way at short notice does not seem plausible. One of the practices to be used to avoid as much as possible this type of situation is to include a milestone in the project’s critical path for the approval of the project (Project Approval Milestone – PAM). Then, express the next dates only as a matter of delays from this milestone date. For example, the analysis will be ended 2 months after the PAM, the design 4 months, the construction 8 months and the phase of test 9 months (PAM + 9 Months). I know, not easy in practice, but it is worth trying it.

Involvement of the customer

Is the date really convenient for the end customer? For example, to deliver a new booking system for a hotel just before peak season is probably not an excellent idea. Maybe would it be better to wait for the following quiet season and to enrich the features, or on the contrary, to minimize functionality to the bare minimum and deliver the system much faster? Also, in accounting some periods are to be avoided to deploy novelties: balance sheets, month end closure, invoicing runs, the tax declarations … It is thus advisable to make sure upfront of the relevance of forced dates coming from sponsors and stakeholders and not to assume that they are fully aware of the customers’ impact.

Resources

For a reason and another, totally independent from your will, it was not possible to you to recruit the resources in time: order forms blocked in purchases, slow controls by the recruiters, delays by certain managers to give the required skills to the project… Nevertheless the sponsors and the stakeholders are not willing to accept any delay!

In fact, they are probably right. It is our job as PM to anticipate, avoid or surmount this type of obstacles and to call upon sponsors to help remove any roadblocks before the project is negatively impacted.

à propos des risques à vouloir imposer des dates irréalistes

Le 9 mars 20101 juillet 2010 par mopertodans best practices, forum de discussion3 commentaires

Il n’est pas rare que les dates du projet, en particulier celle de fin, soit imposées au chef de projet et à son équipe. Sont-elles réalistes? Comment ont-elles été estimées et agréées? Quel est leur fondement?

Voici quelques idées pour mieux appréhender ce problème somme toute très courant.

L’arbitraire…

Rappel des 3 paramètres: Tout projet s’inscrit dans un triangle dont les sommets sont le temps, les coûts et le contenu. Vouloir figer l’un des sommets implique souvent des sacrifices sur l’un ou l’autre des deux autres.

Donc, fixer une échéance calendaire de manière arbitraire peut amener l’équipe projet à essayer de réduire le contenu afin de tenir la date. Cela peut également conduire à un accroissement des coûts par l’utilisation de davantage de ressources pour atteindre à tout prix l’objectif de date ou bien des ressources de compétences supérieures ou de coûts plus importants. Bien sûr, ces deux alternatives généreront les discussions nécessaires avec sponsors et commanditaires pour arriver à un accord. Si la date imposée est absolument irréaliste, il est du devoir du chef de projet de tirer la sonnette d’alarme quitte à refuser le projet (voir le « Code of Ethics and Professional Conduct » de PMI ).

Coté sponsors et commanditaires, il faut être en mesure, et je dirais même se faire un devoir, d’expliquer le pourquoi de dates imposées. Ces raisons peuvent tout à fait être valides et l’équipe projet qui les aura intégrées sera d’autant plus motivée pour les atteindre.

Un exemple vécu fut la mise en place d’un nouveau système de comptabilité dans une grande entreprise internationale. Le sponsor de l’équipe avait pris le temps d’expliquer à l’ensemble des parties prenantes, équipes projet, futurs utilisateurs, et management, l’impératif d’un démarrage sur de nouveaux processus et applicatifs au 1^er janvier. Tout retard aurait causé de grandes difficultés de reprise de l’existant pour l’année en cours, de travail supplémentaire pour chacun… L’ensemble de l’entreprise étant dès lors mobilisée, le déploiement se déroula dans les temps et fut un succès.

Estimations approximatives

Il existe de nombreuses techniques d’estimation plus ou moins scientifiques. Les plus répandues sont les méthodes analogique, paramétrique, intuitive ou avis d’experts, et « Bottom-Up ». Sans entrer dans les détails dans cet article, on estime par analogie en comparant un projet futur à des projets similaires déjà réalisés en extrapolant les estimations. Par exemple, si j’ai déjà implémenté un progiciel dans le pays X et je dois déployer ce même produit dans le pays Y qui de taille et complexité comparables. J’estime par analogie que le coût et les délais pour le pays Y seront sensiblement les mêmes que pour le pays X. La méthode paramétrique s’attache à un haut niveau à définir le ou les paramètres qui permettent d’estimer durée et coûts. Souvent utilisée dans le monde du développement logiciel avec des paramètres tels que le nombre d’écrans, de lignes de code, d’interfaces entre systèmes, et autres « Function Points »… La méthode intuitive est comme son nom l’indique basée sur l’appréciation personnelle de celui qui estime et elle sert principalement à donner un ordre de grandeur. Elle est particulièrement utile en amont pour prioriser les approches et en aval pour identifier des incohérences dans les résultats produits par des méthodes plus détaillées. Les avis d’experts sont souvent utilisés pour rationaliser les résultats intuitifs. Ce ou ces experts puisent dans leur expérience et compétences pour fournir des estimations les plus réalistes possible. Enfin, la méthode « Bottom-Up« , plus analytique exige beaucoup plus de travail détaillé au niveau de chaque livrable du projet pour en estimer efforts, durée et coûts. En général, elle est mise en œuvre grâce à la structure de décomposition du projet, le Work Breakdown Structure (WBS), et l’on s’efforce d’estimer les taches à réaliser au niveau le plus bas possible.

L’idéal est de faire appel à plusieurs méthodes d’estimation et d’en comparer les résultats.

Implication de l’équipe et du chef de projet

Pour que le projet soit un succès, il faudra que l’équipe projet s’approprie les dates, même imposées, ainsi que les estimations d’effort… Si nous prenons l’exemple de Scrum dans le logiciel, au début de chaque itération de développement sur le produit (le Sprint), les membres de l’équipe eux-mêmes ont souvent la possibilité de choisir dans la liste priorisée des besoins clients (le « product backlog ») les livrables qu’ils s’engagent à réaliser sur la période. Ils sont dès lors pleinement engagés sur la tâche et les délais.

Au minimum, le chef de projet doit pouvoir être intimement convaincu que les dates peuvent être tenues pour à son tour motiver son équipe sur les délais, le contenu et la qualité.

Plans réalistes et atteignables

Réalistes pour qui? En premier lieu pour l’équipe. Comme mentionné ci-dessus, le chef de projet et son équipe vont devoir répondre de manière positive aux questions suivantes: Parviendrons-nous à livrer un produit ou service dont nous serons fiers dans les délais? Quels sacrifices cela demandera-t-il et y sommes-nous prêts? Aurons-nous le support nécessaire de nos sponsors?

Vouloir maintenir une date malgré les retards au démarrage

Ce cas est hélas on ne peut plus fréquent. Les estimations fournies sont correctes et la date de fin septembre était atteignable en démarrant au 1^er janvier. Mais voilà, nous sommes le 8 Mars et cela fait plus de trois mois que sponsors et financiers hésitent, posent des questions complémentaires, n’arrivent pas à trouver des créneaux horaires pour se rencontrer… Enfin, ils se sont vus ce matin et sont d’accord, nous avons le feu vert, bonne nouvelle! Et (moins bien) on nous demande de respecter la date de fin septembre et de ne pas dépasser les coûts!!! Cela peut vous paraître familier, j’en suis certain. Cependant, sauf à avoir gonflé outrageusement nos estimations (de 30%) ou pouvoir tailler dans le contenu des livrables, ce sera mission impossible, car accroître le volume de ressources de manière aussi drastique sur une aussi brève échéance semble peu plausible. L’une des pratiques à respecter pour éviter autant que faire se peut ce type de situation est d’inclure un jalon d’approbation du projet (JAP) dans le chemin critique du planning proposé et de n’exprimer les dates suivantes qu’en délais depuis cette date. Par exemple, l’analyse sera terminée 2 mois après le JAP, le design 4 mois, la construction 8 mois et la phase de test 9 mois (JAP + 9 Mois). Je sais, pas facile en pratique, mais cela vaut le coup d’essayer.

Implication du client

La date convient-elle réellement au client final? Par exemple, livrer un nouveau système de réservation hôtelière juste avant la saison touristique ne sera probablement pas une excellente idée. Peut-être vaudrait-il mieux attendre la saison creuse suivante et enrichir les fonctionnalités ou bien, au contraire, réduire celles-ci au strict minimum et livrer le système beaucoup plus tôt? De même, en comptabilité certaines périodes sont à éviter pour livrer des nouveautés: bilans, clôture de fin de mois, facturation, déclarations d’impôts… Il convient donc de bien s’assurer en amont de la pertinence des dates « imposées » par les sponsors et commanditaires et ne pas assumer qu’ils ont conscience de l’impact coté client.

Ressources

Pour une raison x ou y indépendante de votre volonté, il ne vous a pas été possible de recruter les ressources dans les temps: blocage des bons de commande aux achats, contrôles lent des recruteurs, réticences de certains managers à mettre à disposition les compétences requises… Pourtant les sponsors et commanditaires sont prêts à n’accepter aucun délai! En fait, ils ont probablement raison. C’est notre job de PM que d’anticiper, éviter ou surmonter ce type d’obstacles et de faire appel à eux pour faire sauter les blocages éventuels avant que le projet ne soit négativement impacté.

le PMBOK V4 est maintenant disponible en Français

Le 8 mars 20108 mars 2010 par mopertodans best practices, forum de discussion8 commentaires

Le PMI est heureux d’annoncer la sortie de la version française du Guide PMBOK^® – Quatrième édition.

Le Guide PMBOK^® – Quatrième édition poursuit la tradition d’excellence dans le management de projet avec une norme plus facile à comprendre et à mettre en œuvre, avec une plus grande cohérence et clarté.

Quoi de neuf ?

• Un langage normalisé a été incorporé dans tout le document de manière à favoriser la compréhension par le lecteur.
• De nouveaux diagrammes de flux des données clarifient les données d’entrée et de sortie pour chaque processus.
• Une plus grande attention a été accordée au mode d’intégration des domaines de connaissance dans le cadre des groupes de processus de démarrage, de planification, d’exécution, de surveillance et de maîtrise, et de clôture.
• Deux nouveaux processus sont présentés : Identifier les parties prenantes et Recueillir les exigences.

Les membres du PMI ont l’avantage de pouvoir accéder sans frais à la version numérique du Guide PMBOK^®—Quatrième édition.

The file is a watermarked PDF that includes your name and member ID. It is password protected with your PMI.org password and is licensed to you as a member benefit. La distribution, vente ou reproduction de ce fichier n’est pas autorisée.

Pour accéder à la version numérique :

1. Connectez-vous à PMI.org.
2. Click [enter URL]
3. Entrez votre mot de passe PMI.org.
4. Cliquez sur ‘Download’ [Télécharger].
5. Lorsque vous y êtes invité, sélectionnez ‘Save’ [Enregistrer] pour enregistrer le fichier PDF sur le bureau de votre ordinateur.

Pour ouvrir le fichier PDF :

1. Ouvrez le fichier PDF sur le bureau de votre ordinateur.
2. Lorsque vous y êtes invité, entrez votre mot de passe PMI.org puis cliquez sur ‘OK’.

Pour acheter votre exemplaire du Guide PMBOK^®—Quatrième édition :

• Visitez le site commercial de PMI.org (prix pour les membres du PMI : US$49,50) ou
• Renseignez-vous auprès de votre bureau local du PMI ou
• Utilisez l’ISBN à 13 chiffres pour passer votre commande en ligne à niveau local ou dans votre librairie préférée.

Les bénéfices de la Documentation de Projet

Le 4 mars 20101 juillet 2010 par mopertodans best practices, forum de discussion1 commentaire

Voici un article qui m’a interpellé sur le blog de Gina Abudi. Il est écrit par Dhanasekaran Sivaraj et sa version originale en anglais est lisible ici.

Documenter le projet ? ?

“Hummm…je préférerais passer ce temps sur d’autres activités plus importantes du projet.”

“Faisons-le après l’achèvement de toutes les activités du projet, pas tout de suite.”

“Je suis concentré sur la livraison du projet. La documentation peut attendre.”

“Je peux réaliser un projet de plus si je ne fais pas la documentation.”

Cela vous est familier ? Vous pouvez avoir entendu l’une ou toutes les excuses et les complaintes ci-dessus de beaucoup de chefs de projet, vous y compris. Ce sont des déclarations communément utilisées par les chefs de projet qui ne veulent pas faire un travail minutieux – ce qui signifie faire la documentation du projet. Si vous avez prononcé n’importe laquelle de ces phrases, il est temps de déposer une « Requête de Modification » pour changer votre perception de la documentation de projet.

La documentation de projet est un des secteurs les moins intéressants pour les chefs de projet car elle exige de nombreux efforts, mais est rarement applaudie par le chef. En réalité, cependant, la documentation de projet est un composant clef du management de projet et s’exécute du début à la fin de tout projet.

Examinons quelques points clefs à propos de la documentation de projet.

Pourquoi documenter ?

La documentation de projet est exigée pour réussir le projet. Elle est utilisée :

Pour définir le contenu du projet et s’assurer de l’accord de toutes les parties prenantes et des membres de l’équipe. Ainsi, toute personne impliqué dans le projet partage la même compréhension des attentes, de quoi faire, quand le faire, etc.
Pour établir une référence qui permettra de résoudre des différents et entre les parties prenantes si nécessaire.
Pour garder une référence historique qui fournit des informations détaillées sur le projet et peut être utilisée réussir de futurs projets.

Les bénéfices de faire la documentation de projet

En sus de ces raisons, la documentation de projet offre des avantages supplémentaires aux chefs de projet, y compris :

Une aide pour créer les Structures de Répartition de Travail (WBS) très détaillées qui aboutissent à l’élaboration de planning réalistes et réalisables.
Une diminution des surprises et risques inutiles.
Une aide pour prévoir l’avancement du projet pendant l’exécution et prendre des mesures proactives pour attaquer des défis.
Une compréhension claire des pré-requis de projet pour toutes les parties prenantes.

Et…le boss vous verra, le chef de projet, comme une personne soucieuse des détails et minutieuse dans son travail. Ce qui augmente votre valeur dans l’organisation et fait de vous un chef de projet désirable sur tous les projets majeurs.

Résultat final – changez votre perception sur la documentation de projet et commencez à vous concentrer davantage sur ce secteur. Vous commencerez à en voir les bénéfices en un rien de temps et vous augmenterez la probabilité de succès de vos projets avec moins de stress pour vous et pour l’équipe de projet.

Comment vous faire repérer par un chasseur de tête

Le 3 mars 20109 juin 2024 par mopertodans best practicesLaisser un commentaire

Lisez l’article intégral original en Anglais

Bonne nouvelle, selon nos collègues Britanniques, après deux années volatiles, il y aurait des signes de reprise du marché de l’emploi– et les chasseurs de têtes chercheraient des talents pour répondre à la demande.

Pour l’instant, je n’ai pas personnellement ressenti ce redémarrage mais j’espère sincèrement que cette reprise est en train de traverser la Manche sans encombre pendant que j’écris cet article.

Quelques conseils en 4 étapes de BNET pour bien vous positionner dans cette chasse aux talents.

prérequis: attester de 18 mois dans votre job pour montrer votre sérieux, construire une expérience, augmenter la visibilité professionnelle et élargir votre réseau de contacts utiles.

1. Peaufinez votre Curriculum Vitae (CV)

But : S’assurer que son Curriculum Vitae est varié et assez détaillé pour répondre aux attentes.

Votre CV reste votre carte d’entrée, mais les chasseurs de têtes cherchant des managers peuvent le regarder d’un œil plus critique parce qu’ils rechercheront des qualités et compétences spécifiques.

Essayez d’éviter les clichés ou assurez-vous si vous dites que vous êtes ‘proches du terrain’ ou ‘stratégiques et orientés résultats’ que vous pouvez le confirmer par des preuves et des exemples spécifiques.

Une trajectoire de carrière inhabituelle peut jouer en votre faveur si elle démontre une expérience riche et variée – postes à l’étranger, projets à l’extérieur de votre secteur principal et même volontariat montreront que vous avez du répondant.

Un gros handicap serait une suite rapide de changement de jobs. Les chasseurs de têtes aiment voir que vous êtes capables de vous investir dans un rôle.

2. Augmentez votre visibilité

But : Être reconnu comme un expert dans son industrie

Être reconnu de ses pairs serait la chose la plus importante sur laquelle se concentrer pour être remarqué par des chasseurs de têtes. Voici quelques idées :

– Identifiez les séminaires professionnels qui vous semblent pertinents et essayez d’y intervenir en tant que speaker.

– (Re-)Découvrez votre réseau d’anciens étudiants et collègues.

– Gérez votre Identité Numérique : Quelles informations s’affichent quand vous tapez votre nom dans un moteur de recherche ? Votre présence en ligne sera examinée par les chasseurs de têtes, donc cela vaut la peine de vérifier que votre page de LinkedIn (et/ou Viadeo) est à jour et que votre profil de Facebook passe le filtre.

– Rejoignez votre corps professionnel, comme, pour les chefs de projets, PMI ou Prince2 ou IPMA (ou les 3, mais attention aux tarifs).

– Soyez cités : dans les magazines et les sites web de votre industrie ou profession. Recherchez celui que l’on considère comme étant ‘la Bible’ de votre industrie.

3. Courtisez les chasseurs de têtes

But : Entrer dans le radar d’un professionnel de recherche de senior management

Devenez l’un des contacts de plusieurs chasseurs de tête pour leur donner des informations sur vos pairs. La capacité à proposer des candidats potentiels sur un poste témoigne de la qualité de votre propre réseau – et vous les aidez à faire leur travail. Tôt ou tard, ils vous considéreront pour un poste parce que votre nom est toujours le premier qui leur vient à l’esprit.

Évitez les appels « à froid ». Essayez d’être introduit par un ami. Cela facilitera le premier contact.

Une fois que vous avez réussi à faire en sorte que votre chasseur de tête sache que vous existez, vous pouvez être invités pour une réunion en face à face, pour qu’ils puissent déterminer si vous méritez votre réputation.

4. Affûtez votre technique d’entretien

But : S’assurer que la première impression est durable

Vous n’aurez pas de deuxième occasion de faire une bonne première impression. Entraînez-vous à présenter vos compétences et votre expérience et peaufinez votre marque personnelle.

Qu’on le veuille ou pas, la robe importe aussi : Soignez votre apparence.

Écoutez soigneusement ce que l’on vous a demandé et allez au bout de votre pensée dans votre tête avant de répondre. Puis, répondez précisément – comme un cadre supérieur à son bureau exécutif.

Faites quelques recherches sur le chasseur de tête qui vous interviewe – vérifiez le site Web de sa société ou son profil sur les médias sociaux. Il est toujours flatteur qu’un candidat ait fait cet effort.

En conclusion

Excellent! Vous avez été remarqué; vous avez remis un CV impressionnant et avez passé avec succès l’entretien initial; ne vous congratulez pas trop vite. Le vrai boulot commencera quand vous serez présenté pour ce rôle important que vous recherchiez.

Remarques personnelles: J’ajouterais de ne pas oublier que ce job dont vous rêvez se trouve peut-être dans votre propre société. Donc, attachez-vous à appliquer les conseils ci-dessus aux potentiels recruteurs au sein de votre entreprise. Pour être bon face aux chasseurs de têtes, soyez bon dans votre job : la confiance en soi est un atout précieux que ces professionnels perçoivent dès les premiers instants.

10 minutes avec le grand chef pour parler de votre projet

Le 24 février 20101 juillet 2010 par mopertodans best practices, experience sharingLaisser un commentaire

J’ai lu un article de Ty Kiisel qui m’a fait penser aux quelques points à garder à l’esprit lorsque l’on a opportunité de présenter son projet à un ou plusieurs dirigeants.

L’article de Ty s’intitule: « When Presenting to Stakeholders—You’ve Only Got About a Minute ».

Comme Ty, j’ai pu apprécié que l’un des points communs des dirigeants est qu’ils ont très peu de temps. Aussi, leur temps d’attention pour notre projet est très limité et il vaut mieux ne pas gâcher l’opportunité de s’adresser directement à eux si elle se présente. Cela dit, le temps de tout un chacun est précieux. Le temps est une denrée qui nous est donnée en quantité limitée à notre naissance. Donc, soyons concis, adaptons notre propos à notre interlocuteur, attisons son intérêt, soyons précis…

Les 10 points proposés par Ty méritent d’être lus. J’en retiendrais 3 qui sont réellement primordiaux selon mon expérience et j’en ajouterais un que je n’ai pas trouvé dans la liste:

1. Vue d’ensemble (mon addition personnelle): Rappelons le contexte dans lequel s’insère notre projet. N’assumons pas qu’ils se souviennent de qui nous sommes ou l’objet de notre projet. Ils ont beaucoup de choses à gérer en parallèle. Démarrons par la manière dont notre projet supporte un ou plusieurs de leurs objectifs stratégiques avant d’entrer dans les détails. Poursuivons ensuite par un résumé du contenu, coûts, délais, et jalons majeurs du projet. Expliquons où nous en sommes par rapport à ceux-ci.

2. Faisons simple: Soyons directs. Exposons les faits et pourquoi leur implication est nécessaire. Ne les inondons pas d’informations, soyons concis, n’utilisons pas de jargon. Procéder autrement serait un gaspillage de temps et ils penseraient que nous sommes incapables de faire une synthèse efficace et de nous exprimer clairement.

3. Proposons des solutions: Offrons une ou deux options (mais pas plus). Comme Ty l’indique dans son article, il ne nous servirait à rien de présenter des problèmes sans proposition de solution. Ils savent décider entre deux solutions mais c’est notre responsabilité de présenter des options cohérentes et documentées qui mettent en évidence avantages, inconvénients, coûts et impacts sur le projet.

4. Soyons spécifiques sur ce que nous attendons d’eux: Un mémo ou un coup de fil pour débloquer une situation, plus d’argent, de temps, de ressources, un arbitrage, une décision sur les priorités…

B.A.-BA : répondre aux résistances

Le 23 février 20101 juillet 2010 par mopertodans best practices, forum de discussion2 commentaires

Dans un article précédent, j’ai décrit le B.A.-BA: pour conduire des entretiens téléphoniques efficaces. Dans cet article, je voudrais me concentrer sur quelques éléments essentiels pour répondre aux résistances pendant des appels téléphoniques ou des réunions, particulièrement si vous devez vendre un projet ou une idée. De nouveau, rien de neuf sous le soleil pour les chefs de projet expérimentés ou les professionnels de la vente. Mais, ce qui va sans dire, va encore mieux en le disant.

J’ai appris qu’il y a essentiellement trois types différents de résistance qui doivent être reconnus et gérés : Perception incorrecte, Scepticisme et Problème. En réalité, la manière de répondre dans ces trois situations n’est pas si différente mais voyons cela au cas pas cas :

1. Perception incorrecte

Avoir une perception incorrecte c’est soit percevoir inexactement ou bien mal comprendre. Vous vous trouvez dans une situation où, après avoir exposé votre topo, vous avez écouté activement votre interlocuteur. Vous remarquez que votre message n’est pas compris. Il peut y avoir beaucoup de raisons à cela : la manière dont vous vous êtes exprimé; des idées préconçues ou un manque d’écoute de la part de votre interlocuteur; un sujet trop complexe pour être compris du premier coup; un domaine qui exige des connaissances préalables que l’autre personne peut ne pas posséder … Ce qui est nécessaire dans cette situation c’est tout d’abord d’établir qu’il y a une mauvaise perception, de fournir ensuite une clarification et de conclure par une nouvelle écoute et un questionnement pour confirmer l’accord.

Établir qu’il y une mauvaise perception : prouvez, en répétant autant que possible les mots utilisés par la personne, que vous avez identifié une perception incorrecte. Précisez que la faute est la vôtre. Cette mauvaise perception ou ce malentendu est survenu parce que vous n’avez pas encore été capable de transmettre votre message assez clairement pour convaincre la personne.

Par exemple : «je vous entends dire que vous comprenez que ce projet durera 2 ans et exigera 10 membres du personnel de l’entreprise. Je vois que je n’ai pas été clair dans mes explications et je voudrais clarifier ce point spécifique.»

Fournissez la clarification sur l’élément qui n’a pas été bien compris.

Dans notre exemple : «le projet durera en effet 2 ans et nécessitera 10 ressources avec la portée actuellement définie. Cependant, une option présentée est de composer l’équipe à 50/50 entre internes et externes. De plus, une deuxième option est de réduire la portée initiale pour obtenir la plus grande partie possible des bénéfices sur une période plus courte, si vous pensez que c’est souhaitable pour l’entreprise.»

Et concluez avec une nouvelle écoute et des questions pour confirmer l’accord.

Dans notre exemple : «j’ai vu que vous avez hoché la tête quand j’ai clarifié que nous pourrions pourvoir le projet avec 50 % de ressources externes. Sommes-nous d’accord que cette option est une bonne approche pour construire le projet ?»

2. Scepticisme

Le scepticisme s’apparente très souvent à des doutes et un désir de suspendre son jugement par rapport à de nouvelles informations qui ne sont pas très bien supportées par l’argument ou l’évidence présenté. Quand vous remarquez que les informations que vous avez fournies ne sont pas bien acceptées et que ce n’est pas en raison d’un malentendu, mais plutôt du scepticisme, vous êtes dans une situation qui exige l’assurance ou la réassurance. Donc, reconnaissez le scepticisme, rassurez et concluez par une nouvelle écoute et des questions pour confirmer l’accord.

Reconnaissez le scepticisme : vous anticiperez souvent cette réaction potentielle en passant en revue votre proposition ou argumentaire. Vous vous mettez vraiment dans les chaussures de votre homologue pendant un moment et essayez de voir depuis sa perspective ce qui pourrait être douteux dans votre projet ou idée. Dans certains cas, vous pouvez tout simplement vous remémorez que, lorsque vous n’étiez pas encore familier avec le projet, vous aviez également eu des doutes . Utilisez ceux-ci pour montrer que vous comprenez le scepticisme de votre interlocuteur.

Par exemple : « je vois que vous semblez avoir des doutes sur les 2 ans de durée et 240 homme mois d’effort. Très sincèrement, c’était également ma première réaction quand j’ai reçu ces évaluations. »

Rassurez sur le sujet qui génère du scepticisme. Si vous le pouvez, fournissez davantage de faits et preuves sur votre argumentaire. Des benchmarks ou des études, des chiffres de projets antérieurs, des références (particulièrement de personnes que votre homologue connaît bien), des précédents, des statistiques, … sont autant de sources que vous pouvez utiliser pour rassurer la personne sur le sujet.

Dans notre exemple : «Aussi, j’ai questionné l’équipe pour comprendre les détails. Et, ils ont été capables de me montrer les chiffres d’un projet précédent de complexité et portée semblables. Il avait coûté 360mm avec 12 ressources sur 2 ans et demi. Grâce à cette expérience, ils ont été capables de réduire la durée de notre projet à 2 ans et la taille d’équipe à 10 ressources au lieu de 12. Une amélioration de 30 % et avec une équipe qui a déjà réalisé un projet semblable.»

Et concluez avec une nouvelle session d’écoute et de questionnement pour accord.

Dans notre exemple : «vous avez semblé être sur la même longueur d’ondes que moi quand j’ai exposé la façon dont les évaluations ont été construites. Êtes-vous plus à l’aise avec cet aspect du projet ?»

3. Problème

«J’ai un problème …» est la méthode traditionnelle de remonter une préoccupation, un souci, lors d’une réunion. C’est une déclaration très puissante et qui, si elle n’est pas réglée, peut tout stopper. Si votre contrepartie ne l’exprime pas ouvertement, mais vous pouvez voir qu’il y a un problème réel pour lui ou elle, posez la question: «À votre avis, quel pourrait-être le problème-clé ou la préoccupation que le projet devrait adresser en priorité ?». De nouveau, ce qui est exigé dans cette situation est en premier lieu de reconnaître qu’il y a un problème, ensuite réaffirmer les points forts de votre proposition, chercher une résolution et conclure par une nouvelle écoute et des questions pour confirmer l’accord.

Reconnaissez le problème : assurez-vous que vous comprenez précisément le souci. Est-ce le coût, les délais, le contenu, l’approche, la dotation en personnel, les compétences, les conditions de paiement ? Prouvez, en réutilisant autant que possible les mots de la personne, que vous avez vraiment compris où se situe le problème.

Par exemple : «je vous entends mentionner comme un problème le fait que le projet durera 2 ans et exigera 10 membres du personnel interne. Et que la durée est une réelle préoccupation ou un point de blocage pour vous parce que votre fenêtre d’opportunité pour lancer ces nouveaux services sur le marché n’est que de 18 mois.»

Réaffirmez les points forts de votre proposition et utilisez des accords établis précédemment pour renforcer les bénéfices escomptés. Réitérez l’équation besoins/bénéfices du projet.

Dans notre exemple : «Nous avons établi ensemble que ce nouveau projet est absolument nécessaire pour permettre à la société de livrer ces nouveaux services. Des études préalables ont établi que des modifications aux systèmes existants coûteraient davantage et demanderaient plus de temps. De plus, nous sommes d’accord sur la portée du projet en termes de contenu et d’évaluation des charges. Ce projet permettra aux nouveaux services d’être développés et exploités efficacement.»

Cherchez la résolution avec votre contrepartie pour éliminer ou contourner le problème.

Dans notre exemple : Ce projet durera en effet 2 ans avec 10 ressources pour la portée actuellement définie. Cependant, une option que nous avons examinée est de réduire la durée en amenant des ressources supplémentaires pour exécuter certaines tâches en parallèle plutôt que séquentiellement. D’autre part, nous avons également l’option mentionnée précédemment de réduire la portée initiale pour nous concentrer sur les fonctions les plus critiques. Celles qui permettront de répondre à la majorité des besoins sous 18 mois, avec quelques adaptations de processus. Puis, nous livrerons une version qui couvrira la totalité du périmètre un peu plus tard.»

Et concluez avec une nouvelle écoute et questionnement pour accord.

Dans notre exemple : «j’ai vu que vous avez été sensible à l’option d’ajouter du personnel externe sur le projet. Sommes-nous d’accord que ce serait une bonne approche pour avancer sur le projet ?»

Bien sûr, les chefs de projet ne sont pas des commerciaux professionnels, mais connaître quelque-unes des ficelles pour mieux répondre aux résistances pendant des réunions est une compétence fort utile dans nos vies professionnelle et privée.

B.A.-BA – conduire des entretiens téléphoniques efficaces

Le 18 février 2010 par mopertodans best practices, forum de discussion1 commentaire

Je suis souvent étonné du manque apparent de professionnalisme dont font preuve certaines personnes dans leur manière de conduire des entretiens téléphoniques. En particulier lorsqu’ils ont lieu avec des clients, prospects, commanditaires, ou des niveaux de direction.

Je me demande si certaines des bases que nous avons appris très tôt dans notre vie professionnelle n’ont pas été oubliées. Dans mon cas, cet apprentissage s’est déroulé alors que les téléphones portables étaient « portatifs », la messagerie instantanée à inventer, sans parler des gazouillis de Twitter… C’était également une époque où les coûts de télécommunication étaient beaucoup plus élevés que de nos jours. Ceci explique peu-être pourquoi certaines de ces bases pourraient vous paraître dépassées. Pourtant, je les trouve encore extrêmement d’actualité dans mes communications téléphoniques. Je considère qu’elles démontrent un respect envers mon interlocuteur et le temps qu’il ou elle me consacre.

Vu le temps que les chefs de projet passent sur ce type de communication, J’ai pensé qu’il pourrait être utile de partager la structure que j’essaie toujours de suivre. C’est en fait très simple:

1. saluer la personne, se présenter et créer une atmosphère: si c’est une personne avec laquelle je parle souvent et connais assez bien, il est facile de rompre la glace avec quelques mots sur un sujet d’intérêt commun. Sinon, je reprends mes notes d’interactions passées ou je fais une rapide recherche Google , LinkedIn ou Viadeo pour trouver une accroche. Et, si la personne est référencée sur votre annuaire d’entreprise intranet, lisez sa fiche et regardez sa photo pour mettre un visage sur le nom.

2. positionner: confirmer le pourquoi de l’entretien et ses objectifs.

3. confirmer la durée: valider l’heure à laquelle l’entretien devra prendre fin et ne pas en déroger sauf sur demande de la personne appelée.

4. communiquer le plan de l’entretien: lister les sujets que vous aimeriez couvrir pendant cette session. Cela permet de se repérer pendant l’appel, cela évite les surprises, et aide à structurer l’appel et à gérer le temps.

5. écouter, valider l’accord: confirmer avec la personne que le plan proposé lui convient et demander si d’autres sujets devraient être ajoutés (ou certains enlevés).

6. dérouler l’appel en suivant le plan proposé et en s’assurant sur chaque point d’une compréhension commune par des questions de vérification et de validation.

7. faire un résumé de l’appel: Cette étape me permet de vérifier mes notes; de m’assurer que tous les sujets ont été couverts et si cela n’est pas le cas prévoir un appel ultérieur; et, d’expliciter ma compréhension de ce qui a été dit.

8. écouter, valider l’accord: Prendre le temps de vérifier que ma compréhension est correcte et que je n’ai rien oublié.

9. prendre note des actions: Il est temps de vérifier que nous avons bien un jeu commun d’actions agréées.

10. écouter, valider l’approbation: Pour confirmer nos engagements respectifs sur ces actions.

11. remercier la personne de son temps et contributions et pour les actions qu’elle a accepté de mener.

Ensuite, je m’efforce de ne jamais oublier de faire un suivi des actions sur lesquelles nous sommes d’accord.

back to basics for running effective calls

Le 17 février 201017 février 2010 par mopertodans best practices, forum de discussion3 commentaires

I’m often amazed by the apparent lack of professionalism some people demonstrate in running calls, especially with sponsors, customers, prospects, senior management…

I wonder if some of the basics we learned early in our careers have not been forgotten. In my case, I learned these when cell phones, instant messaging, tweets… did not yet exist, and also at a time when telecoms costs were much more significant than Today. This may explain why some of these basics may seem a bit outdated. However, I personally still find them very very relevant in my day to day communications. I think that they also are a display of my respect towards the person I’m calling and for the time he or she dedicates to discuss with me.

Given time that Project Managers spend on calls, I thought that it could be useful to share how I always try to structure to be in good position. It is quite simple:

1. greet, introduce and relate: if I speak frequently with the person, it is quite simple to find « small talk » topics to break the ice. If I do not know the person very well, I’ll try to refer back to my notes from prior interactions, or perform a quick Google or LinkedIn search. And, if the person is referenced on the intranet directory, look at her information and picture to put a face on the name.

2. position: confirm the purpose and objectives of the call

3. confirm timing: confirm until when you have for this call and then do not overrun unless requested by the person you call

4. communicate plan: provide a rapid outline of the topics you’d like to cover during the call. It avoids surprises, it helps to structure the call and also it gives a way to check progress versus time allotted for the call.

5. listen/probe for agreement: confirm with the person that this plan is OK and ask if topics should be added or removed in their opinion.

6. run the call following the above plan and constantly probing, listening and confirming my/our mutual understanding

7. summarize the call: This step allows me to check my notes, verify that all topics we wanted to cover have been. And, if it’s not the case agree to a follow up call. Repeat my understanding of what has been said.

8. listen/probe for agreement: Take the time to check that my understanding is correct and verify that I haven’t missed any point.

9. propose actions: Now it’s time to double check that we have a common set of agreed actions.

10. listen/probe for commitment: This is to confirm our respective commitments to conduct the above actions

11. thank the person for their time and contributions and for accepting some of the above actions.

Then, I try to never forget to follow through on the actions we agreed.

why quick fixes often lead to more trouble

Le 25 janvier 20101 juillet 2010 par mopertodans best practices, forum de discussion1 commentaire

As project managers, we’re often compelled to get roadblocks out of the way as fast as possible so the team can continue to progress. Therefore, we’re quite often in problem solving mode, trying to resolve issues that arise, avoiding and mitigating risks. A useful thing to keep in mind is to always consider whether we are really addressing the issue or only a symptom of the issue. Is our quick fix action aimed at the root cause of the issue or is it a step in the right direction as we fix the symptom? If yes, that’s ok and we shall apply the quick fix. But it’s not always the case…

This post is inspired by a training session I organized and attended for the management board of the PMI France-Sud non-profit organization a couple of years ago. Jerry Brightman, a renowned leadership expert and President of a company called The Leadership Group, was kind enough to facilitate this session.

Let’s take an example to illustrate the topic: a team member comes into your office to announce a probable delay on one of his deliverables. I propose that we walk through this case to better understand what could be happening.

The way it usually starts:

1. We see a problem, or to be more precise the symptom of a problem. I.e. by definition of a symptom: « a sign, indication, manifestation; something caused by and indicative of a certain disease or disorder. » In this example, a team member signals that he may not be delivering his part of the project on time.

2.We apply a quick fix. This deliverable is on our critical path, we propose to provide some additional assistance to the person to get the task completed on time.

Let’s assume that indeed this fixes the symptom. In our example, the task is back on track.

However, are we sure to have

a) addressed the root cause of the problem and

b) assessed the potential side effects of the quick fix we applied?

Let’s see what too often takes place after the initial quick fix.

3. The quick fix addresses the symptom but it has some side effects. For example, the additional help provided provokes a delay on another task from which we pulled some resources, or it generates requests from many others to get more resources, or it demotivates team members who were going the extra-mile to be on time, or…

4. These side effects will manifest through new symptoms: Bad morale in the team, threats of delays in other parts of the project, absenteeism…

5. We’re tempted to address these new symptoms with more quick fixes.

The loop goes on. The initial quick fix may have placed the entire project at risk.

So, what to do? How do we break the vicious spiral?

The proposal is to try by all means to avoid entering into this spiral.

In step 1, when we see the symptom (the threat of a late deliverable that is on the critical path), we take a step back to understand why the symptom is there and what caused it. We will want to ask a few questions such as:

Were the estimates incorrect?
Did a risk materialize that we had or not accounted for?
Were there changes to the requirements and how were these managed?
Were some resources not available when they should have been?
Was the learning curve incorrectly appreciated?
Did we encounter technical issues?

We see that the answers to the above questions may drive us in step 2 to a completely different quick fix that should be better suited to address the primary/root cause and avoid or anticipate some of the side effects.

As Seth Godkin highlighted it in of his posts: Bear shaving will not resolve global warning.

Or what my first aid teacher repeated to his students: « Do not put a Band-Aid on a non disinfected wound. »

Pourquoi les réparations rapides amènent-elles souvent plus de problèmes qu’elles n’en résolvent ?

Le 25 janvier 20101 juillet 2010 par mopertodans best practices, outils et méthodesLaisser un commentaire

L’un des rôles du chef de projet est d’éliminer le plus rapidement possible tout obstacle qui empêcherait l’équipe de progresser. Nous sommes donc souvent en mode « résolution de problème », essayant de répondre aux questions qui surgissent, d’éviter et/ou atténuer les risques. Il est utile de nous poser la question de savoir si ce que nous essayons de résoudre est réellement le problème ou seulement un symptôme du problème. Notre réponse ou réparation rapide s’attaque-t-elle à la cause première/racine du problème ? Est-ce une étape dans la bonne direction pour réparer le problème de fond ? Si oui, ok pour cette réparation rapide (« quick fix »). Mais cela n’est pas toujours le cas …

Cet article est inspiré d’une session de formation que j’avais organisée et suivie pour le bureau de l’association PMI France-Sud. Jerry Brightman, un expert renommé du leadership et Président de la société The Leadership Group, fut l’animateur de cette session.

Prenons un exemple pour illustrer le sujet : un membre de l’équipe entre dans votre bureau pour annoncer un possible retard sur l’un de ses futurs livrables. Je propose que nous suivions ce cas pas à pas pour mieux comprendre ce qui pourrait arriver.

Voici comment cela commence habituellement :

1. Nous voyons un problème, ou pour être plus exacts le symptôme d’un problème. C’est-à-dire selon la définition du mot symptôme : « un signe, une indication, une manifestation; quelque chose de causé par et indicatif d’une certaine maladie ou désordre. » Dans notre exemple, le symptôme est le signal de l’un des membres de l’équipe qu’il ne livrera probablement pas sa partie dans les temps.

2. Nous appliquons alors une réparation rapide. Ce livrable est sur notre chemin critique, nous proposons de fournir un peu d’aide supplémentaire à la personne pour l’achever dans les délais prévus.

Supposons que cela fonctionne et répare en effet le symptôme. Dans notre exemple, la tâche à réaliser est de nouveau dans les temps.

Cependant, sommes-nous sûr d’avoir

a) Attaqué la cause première/racine du problème et

b) Évalué les effets secondaires potentiels de la réparation rapide ?

Voyons ce qui arrive trop souvent après une réparation rapide.

3. La réparation rapide adresse le symptôme mais elle a quelques effets secondaires. Par exemple, l’aide supplémentaire sur une tâche provoque un retard sur une autre tâche dont nous avons utilisé des ressources, ou elle produit des requêtes d’autres membres pour obtenir davantage de ressources, ou elle démotive les membres de l’équipe qui fournissaient des efforts supplémentaires importants pour rester dans les temps sur leurs propres parties du projet, ou …

4. Ces effets secondaires se manifesteront par de nouveaux symptômes : mauvais moral dans l’équipe, menaces de retards sur d’autres parties du projet, absentéisme …

5. Nous serons tentés d’adresser ces nouveaux symptômes par davantage de réparations rapides.

La boucle continue. Cette réparation rapide initiale peut avoir placé tout le projet à risque.

Aussi, que faire ? Comment casser ce cercle vicieux ?

La proposition est de s’efforcer par tous les moyens d’éviter d’entrer dans cette spirale.

Dans l’étape 1, quand nous observons le symptôme (la menace du retard d’un livrable qui se trouve sur le chemin critique), nous prenons un peu de recul pour comprendre pourquoi le symptôme est là et quelle en est la cause. Nous nous posons ainsi qu’à l’équipe certaines questions telles que:

Est-ce que les évaluations de charge étaient incorrectes ?
Un risque s’est-il matérialisé que nous n’avions pas prévu ou incorrectement managé ?
Un changement des besoins est-il intervenu et comment a-t-il été géré ?
Est-ce que des ressources n’étaient pas disponibles quand elles auraient dues l’être ?
La courbe d’apprentissage a-t-elle été mal appréciée ?
Avons-nous rencontré des difficultés techniques ?

Nous voyons que les réponses aux susdites questions peuvent nous amener dans un 2^ème étape à une réparation rapide peut-être totalement différente et qui devrait être plus adaptée pour adresser la cause première/racine et éviter ou anticiper certains des effets secondaires.

Comme Seth Godkin l’avait mis en évidence dans un article : Raser les ours polaires ne résoudra pas le réchauffement climatique.

Ou encore, comme mon enseignant en premiers secours le répétait à ses étudiants : « Ne mettez pas de pansement sur une blessure qui n’est pas désinfectée. »

Objectif

Informations

Contrôle efficace

Développement progressif

Disponibilité Contrainte

Que déléguer

Négociation

Quand tout est fait pour vous

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

Quels critères pouvons-nous utiliser pour identifier à coup sûr les meilleures pratiques ?

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

Qu’ajouteriez-vous à ce début de liste ?

partagez ce billet avec vos amis, collègues et relations professionnelles

Secrets to Successful Outsourcing – Part 1 & Part 2

partagez ce billet avec vos amis, collègues et relations professionnelles

False Idea n°1: the Agile Methods apply only to « small » projects

False Idea n°2: the classification « Agile Method » determines a homogeneous group

False Idea n°3: the Agile Methods are methods of project management

False Idea n°4: the Agile Methods are methods of rapid development or prototyping

False Idea n°5: the agile developments are with difficult to maintain because of the lack of documentation

False Idea n°6: the Agile Methods, it is the freedom to do it its own way

False Idea n°7: the Agility, it is simple thus it is easy

False Idea n°8: the Agile Methods require senior developers

False Idea n°9: incompatibility with the classic approaches

False Idea n°10: the Agility can apply to anything and everything

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

The arbitrary…

Rough estimates

Involvement of the team and the project manager

Realistic and reachable plans

Maintaining a completion date in spite of the delays to start

Involvement of the customer

Resources

partagez ce billet avec vos amis, collègues et relations professionnelles

L’arbitraire…

Estimations approximatives

Implication de l’équipe et du chef de projet

Plans réalistes et atteignables

Vouloir maintenir une date malgré les retards au démarrage

Implication du client

Ressources

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

Documenter le projet ? ?

Pourquoi documenter ?

Les bénéfices de faire la documentation de projet

partagez ce billet avec vos amis, collègues et relations professionnelles

1. Peaufinez votre Curriculum Vitae (CV)

2. Augmentez votre visibilité

3. Courtisez les chasseurs de têtes

4. Affûtez votre technique d’entretien

En conclusion

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

1. Perception incorrecte

2. Scepticisme

3. Problème

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

partagez ce billet avec vos amis, collègues et relations professionnelles

The way it usually starts:

Let’s see what too often takes place after the initial quick fix.

So, what to do? How do we break the vicious spiral?

partagez ce billet avec vos amis, collègues et relations professionnelles

Voici comment cela commence habituellement :

Voyons ce qui arrive trop souvent après une réparation rapide.

partagez ce billet avec vos amis, collègues et relations professionnelles