articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
meilleures pratiques
John McWade prodigue ses conseils avisés sur le site « Before & After ».
Plusieurs sont disponibles gratuitement, dont cette vidéo sur comment créer rapidement et sans beaucoup de moyens un logo qui semble professionnel pour votre projet ou programme.
Donc, voici comment vous y prendre en 2’30 » top chrono:
Ce prix, à haute valeur symbolique, a été créé afin d’encourager les projets innovants et remarquables dans la francophonie au sens large. Créé et sponsorisé par la SMP et le PMI Switzerland Chapter, il est ouvert aux personnes individuelles et entreprises de type PME et start-up qui ont élaboré et réalisé des projets répondant aux valeurs et critères majeurs des référentiels IPMA et PMI.
Le concours est ouvert aux personnes individuelles et entreprises qui ont élaboré, réalisé et mis en oeuvre un projet présentant les caractéristiques suivantes, relatives aux référentiels majeurs, notamment IPMA, PMI, PRINCE2, HERMES :
Le prix de CHF. 5’000.- récompense le chef de projet et son équipe.
Détails et dossier de candidature sur: http://www.project-management.ch/
L’auteur de cet article nous propose d’appliquer cette approche et technique au management de projet entre autres pour toute activité de type « brainstorming » (remue-méninges) telles que créer le WBS, identifier risques et opportunités, ou rassembler les leçons apprises. J’ai également entendu dire que Delphi a été utilisé dans certains conflits entre pays pour parvenir à un accord consensuel qui évite ou arrête l’affrontement par les armes. « Qui peut le plus peut le moins », cette méthode pourrait donc vous être une aide utile pour arriver à un consensus sur le prochain sujet épineux de votre projet où certaines personnes campent sur leurs positions et refusent d’en bouger.
En tant que chef de projet, il est important de penser à quels événements futurs pourraient avoir un impact sur votre projet. Ces événements peuvent être positifs ou négatifs, donc leur compréhension vous permet de préparer et de mettre en place des plans d’action. Mais comment pouvez-vous prédire l’avenir avec un quelconque degré de certitude ? C’est un endroit où la Technique Delphi peut aider.
La Technique Delphi est une méthode utilisée pour évaluer la probabilité et le résultat d’événements futurs. Un groupe d’experts est réuni et ils échangent leurs vues et chacun donne individuellement des évaluations et des suppositions à un facilitateur/animateur qui passe en revue les données et publie un rapport résumé.
Les membres du groupe discutent et passent en revue individuellement le rapport résumé et donnent des prévisions mises à jour au facilitateur, qui passe de nouveau en revue le matériel et publie un deuxième rapport. Ce processus continue jusqu’à ce que tous les participants atteignent un consensus.
Les experts à chaque tour de revue ont un rapport complet des prévisions d’autres experts, mais ils ne savent pas qui les a prédites. L’anonymat permet aux experts d’exprimer librement leurs avis, encourage la franchise et évite d’avoir à admettre des erreurs en changeant des prévisions précédentes.
Cet article se penche sur comment exécuter une session Delphi. A la fin de la lecture de ce guide vous serez capables d’exécuter une session vous permettant de prévoir des événements futurs et leur impact sur votre projet.
La technique est un processus itératif et aspire en premier lieu à obtenir une vaste gamme d’opinions du groupe d’experts. Les résultats du premier round de questions, quand récapitulé, fournissent la base pour le deuxième round de questions. Le résultat du deuxième tour aliment le troisième et dernier round.
Le but est de clarifier et d’entrer dans le détail de ces problèmes, d’identifier les secteurs d’accord ou de désaccord et de commencer à dégager un consensus.
La première étape doit choisir votre facilitateur. Vous pouvez vouloir vous-même tenir ce rôle, ou trouver une personne ‘neutre’ dans votre organisation. Il est utile d’avoir quelqu’un qui est familier avec la recherche et la collecte de données.
La technique Delphi repose sur un panel d’experts. Ce panel peut être votre équipe projet, y compris le client, ou d’autres experts au sein de votre organisation ou industrie. Un expert est « tout individu avec la connaissance appropriée et l’expérience sur un sujet particulier. » ¹
Quel est le problème ou la question que vous cherchez à comprendre ? Les experts doivent comprendre exactement ce sur quoi ils commentent, assurez si que vous fournissez une définition claire et complète.
Étape 4 : Premier round de questionsPosez des questions générales pour acquérir une compréhension d’ensemble des vues des experts à propos d’événements futurs. Les questions peuvent être présentées sous forme de questionnaires ou d’enquêtes. Collationnez et récapitulez les réponses en supprimant tout contenu sans rapport et en cherchant des points de vue communs.
Basé sur les réponses aux premières questions, ces questions devraient fouiller le sujet plus en profondeur pour clarifier des problèmes spécifiques. Ces questions peuvent aussi être présentées sous forme de questionnaires ou d’enquêtes. De nouveau, collationnez et récapitulez les réponses en supprimant tout contenu sans rapport et en cherchant des points de vue communs. Souvenez-vous, nous cherchons à construire le consensus.
Le questionnaire final aspire à se concentrer sur le soutien de la prise de décision. Focalisez-vous sur les secteurs d’agrément. Sur quoi les experts sont-ils tous d’accord ? (Vous pouvez vouloir avoir plus de trois rounds d’interrogation pour atteindre un consensus plus resserré.)
Après ce round de questions vos experts auront, nous espérons, atteint un consensus et vous aurez une vue des événements futurs. Analysez ces découvertes et mettez en place des plans pour traiter ces futurs risques et opportunités de votre projet.
Utilisez la Technique Delphi pour créer des Structures de Répartition du Travail (Work Breakdown Structures – WBS), identifier des risques et des opportunités, compiler des leçons apprises et toute période de temps que vous utiliseriez normalement pour du brainstorming.
Prévoir l’avenir n’est pas une science exacte, mais la technique Delphi peut vous aider à comprendre la probabilité d’événements futurs et quels impacts ils pourraient avoir sur votre projet.
¹ Cantrill JA, SibbaldB, Buetow S. The Delphi and Nominal Group Techniques in Health Services Research. International Journal of Pharmacy Practice 1996;4:67-74
Je ne suis pas un adepte du travail au chronomètre. Je suis par contre certain que la concentration sur une tâche unique pendant un laps de temps suffisant et sans interruption est plus productive que de passer de tâche en tâche en changeant de contexte fréquemment ou bien encore de se laisser détourner de sa tâche par des interruptions intempestives. Aussi, je peux facilement reconnaître le bien-fondé de certains des arguments avancés par Red Tani en faveur du « timeboxing ».
Le «Timeboxing» est une technique de gestion du temps qui limite le temps pendant lequel une tâche (ou jeu de tâches) est accomplie. Bien qu’il soit généralement utilisé par des équipes de développement logiciel, de plus en plus de personnes (des designers, des auteurs, des ingénieurs — même des étudiants) l’utilisent pour augmenter leur productivité personnelle. Pourquoi ? Voici cinq bonnes raisons.
Vous ne devez pas acheter quoi que ce soit. Le seul gadget dont vous aurez besoin est un minuteur, que vous avez probablement dans votre cuisine ou sur votre téléphone portable et ordinateur. Si ce n’était pas le cas, il y a les tonnes de logiciels en ligne.
Vous ne devez pas lire de longs livres ou suivre des séminaires chers pour l’apprendre. Bien qu’il y ait beaucoup de variations du «Timeboxing», les étapes de base sont essentiellement les mêmes :
N’importe laquelle des susdites étapes peut être ajustée. Pour ceux qui souffrent de perfectionnisme sévère ou de procrastination, le laps de temps peut être aussi réduit que 5 minutes pour rendre la tâche moins intimidante. D’autre part, les drogués du travail peuvent utiliser le « timeboxing » pour limiter la durée de travail, rendant ainsi le travail moins stressant.
Quand on en vient au choix des tâches à limiter dans le temps, vous pouvez être très spécifique (“Écrire une description en 100 mots de mon personnage principal.”) ou plus vague (“Réaliser un certain progrès sur mon roman.”) à vous de choisir.
Le « timeboxing » peut aussi être utilisé pour des activités d’autres que le travail. Vous pouvez limiter dans le temps des tâches ménagères pour les transformer en jeux (“Ranger mon bureau en moins de dix minutes. Prêt, partez!”) Vous pouvez aussi limiter dans le temps des activités improductives (“Consulter Facebook pendant pas plus que cinq minutes.”) Vous pouvez même des combinaisons de « Timeboxing », comme celles utilisés dans Procrastination Dash et Pomodoro Technique.
Le démarrage sur une tâche est souvent plus difficile que de faire la tâche elle-même. Le «Timeboxing» rend le départ moins intimidant. Il est beaucoup plus facile de commencer sur une tâche que vous devez faire pendant seulement quinze minutes que sur quelque chose où vous devez passer un temps indéfini. Parce que quand vous pensez au travail et au temps d’une façon indéfinie, c’est souvent extrêmement long.
La configuration de la durée d’un minuteur dans le temps vous force aussi à choisir une quantité de travail appropriée. Si vous avez seulement trente minutes pour travailler, vous n’essayerez pas “d’écrire un livre.” “Écrire le premier jet du chapitre 1 ″ est non seulement plus réaliste, c’est aussi moins intimidant – demander à quelqu’un qui s’est assis et a essayé d’écrire « Le Grand Roman Américain ».
La procrastination est souvent causée ou au moins liée au perfectionnisme. Non seulement les perfectionnistes ont beaucoup de mal à commencer, ils trouvent difficile de continuer et parfois, même de finir. Le «Timeboxing» diminue l’aversion à et le stress de la tâche en limitant sa durée.
Mais il y a une autre manière dont la limitation dans le temps peut restreindre le perfectionnisme. En mettant des buts spécifiques à accomplir avant que le temps ne soit écoulé, le perfectionniste est forcé de s’en tenir au suffisamment bon, de donner la priorité aux objets de première nécessité et d’éviter d’aller dans les détails. Et si le superficiel ne peut pas être totalement évité, il peut au moins être limité dans le temps. Cela assure que le travail sera fini à l’heure — et non ruiné en bricolant trop.
Les perfectionnistes rendent le travail trop stimulant en donnant des buts peu réalistes, souvent avec des standards qui sont trop élevés. A l’inverse, quand les buts sont trop insignifiants ou les standards trop faibles, le travail devient trop facile, aboutissant à l’ennui. Quand le travail n’est ni trop facile, ni trop difficile, cela devient aisé, même agréable et fortement productif. Cet état heureux est appelé « Flow ».
Les conditions qui incitent le « flow » peuvent facilement être créées en se limitant dans le temps :
Pendant le « flow », vous concentrez toute votre capacité émotionnelle et intellectuelle sur la tâche à portée de main, vous permettant de réaliser votre meilleur travail. (Assurez-vous juste que votre minuteur est assez puissant pour vous rendre à la réalité à la fin du temps imparti.)
Le «Timeboxing» peut être simple comparé à d’autres outils de gestion du temps, mais comme je vous l’ai montré, ses avantages sont multiples. Il y a d’autres raisons de pratiquer le «Timeboxing» — c’est plus durable, plus facile à prévoir et à mesurer, meilleur pour votre santé — mais je suis sûr qu’une fois que vous l’aurez essayé, vous trouverez votre propre raison de l’utiliser.
Pourquoi ne lui donneriez-vous pas une chance ?
Faites une liste des tâches que vous avez remis à plus tard. Allez-y! Démarrez votre traitement de texte, mettez votre minuteur et commencez à écrire.
Voici quelques conseils additionnels pour bien préparer vos prochaines interventions qui complète l’un de mes billets précédents: une bonne préparation permet de réaliser de meilleures présentations dans les conférences
Si vous êtes dans l’audience plutôt que sur scène, n’oubliez pas de lire: comment tirer le maximum des événements professionnels auxquels vous participez
Que vous deviez donner des présentations occasionnellement ou régulièrement, il est important de vous préparer efficacement en avance pour la présentation pour vous assurer que vous atteindrez vos buts. Rappelez-vous que les présentations sont essentielles au business. Elles informent et instruisent votre auditoire et leur permettent de vous connaître ainsi que votre société par leur biais. Vous pouvez utiliser une présentation pour convaincre un client d’utiliser votre produit ou service plutôt que ceux d’un concurrent. Plus votre présentation est concise et ciblée, plus vous êtes dynamique dans la présentation de l’information à votre auditoire, plus probablement le résultat sera réussi.
Il y a quelques choses auxquelles vous devriez penser avant que vous ne développiez votre présentation, dont :
Regardons chacune d’entre elles dans plus de détail.
Quelle connaissance votre auditoire possède-t-il du sujet que vous présentez ? En connaissent-ils déjà une bonne partie et ont-ils besoin d’information spécifique, ou cherchent-ils une vue d’ensemble ou une introduction du sujet ? Vous attendez-vous à ce qu’ils soient satisfaits de l’information que vous délivrez – est-ce le message qu’ils veulent entendre ? Ou…plutôt, le message est-il négatif pour eux ? Combien de personnes suivront la présentation ? Y-a-t-il possibilité de réaliser une session interactive avec beaucoup de questions et réponses, ou bien – présentez-vous à un très grand groupe pour transmettre de l’information et non pas rechercher de l’interactivité ?
Plus vous connaissez de votre auditoire et leurs attentes; mieux vous pouvez préparer la présentation pour vous assurer qu’elle est efficace et fournit à l’auditoire ce qu’ils veulent et ont besoin de votre part.
Pensez à ce que vous essayez de réaliser avec cette présentation. Est-ce qu’une décision est attendue à la fin de la présentation pour enclencher quelque chose ? Est-ce que la présentation va seulement donner matière à réflexion ? Est-ce une session de suivi fournissant le statut d’un projet ? Essayez-vous de vendre à d’autres votre idée et de faire approuver un budget ? Le but de la présentation guidera ce que vous développerez.
Par exemple, si la présentation est concentrée sur l’obtention de l’approbation d’un budget pour avancer avec un projet, vous voudrez inclure des études de cas et exemples de projets passés. Vous voudrez être sûr que votre auditoire comprend la valeur d’y aller – quel sera le résultat final et comment il leur profitera ?
Gardez votre présentation succincte et précise – présentez aussi peu de messages clefs que possible pour garantir la compréhension et avoir un impact sur votre auditoire. Vous ne voulez pas que votre présentation en donne tant qu’ils n’auront aucune idée du but de la présentation ni de ce qu’ils doivent faire.
Si vous avez des documents à distribuer et qu’ils ne sont pas nécessaires pour la présentation, mais sont plutôt à prendre en partant pour référence, fournissez-les à la fin de la présentation pour qu’ils ne les distraient pas de votre présentation.
Une règle de préparation et de présentation efficace est : “dire à l’auditoire ce que vous allez leur dire, le leur dire et leur rappeler enfin ce que vous venez de leur dire.” Sans doute avez-vous entendu cette règle plusieurs fois. Utilisez-la pour structurer votre présentation :
Nous discuterons de ces sections ci-dessous.
Tenez compte en développant votre présentation du fait que les diapositives vont soutenir votre propos; vous ne devriez pas lire des diapositives, mais plutôt utiliser le contenu des diapositives comme un rappel de ce que vous présentez à l’auditoire.
Si votre présentation dure plus d’une heure, assurez-vous qu’il y a au moins 15 minutes de pauses sur la durée.
Regardons chacune des sections de la présentation dans un peu plus de détail.
Les diapositives d’introduction devraient inclure :
Le point principal des diapositives d’introduction est de présenter la présentation pour que les gens sachent à quoi s’attendre. Communiquez-leur la durée la présentation (rappelez-vous toujours laisser du temps pour les questions!). Si vous préférez que les questions soient traitées à la fin de la présentation, faites le savoir dès le départ. Demandez si l’auditoire a des questions avant d’entamer la partie principale de la présentation.
Les diapositives de message, ou de contenu, sont la partie principale de votre présentation. Rappelez-vous la règle ci-dessus ? Voici le moment où vous “leur dites” ce que vous avez dit que vous alliez leur dire. La majorité de vos diapositives se trouvera dans cette section. Vous pouvez découper cette section en de multiples sections plus petites si nécessaire, particulièrement pour des présentations longues. Si vous découpez votre présentation en sections plus petites, assurez-vous que chaque section a sa propre page d’introduction (et agenda pour cette section) et une diapositive de résumé qui boucle la section.
Quelques meilleures pratiques pour vos diapositives incluent :
Vos diapositives de résumé récapituleront les points principaux de votre présentation. “Rappelez à votre auditoire ce que vous venez de leur dire.” Une session de questions et réponses fera partie de votre résumé. Demandez à l’auditoire s’ils ont des questions sur votre présentation. Répondez aux questions clairement et précisément. Si vous ne connaissez pas la réponse, c’est acceptable – admettez que vous n’êtes pas sûrs de la réponse et dites à la personne qui l’a posez que vous reviendrez vers elle quand vous l’aurez. Et rappelez-vous de donner suite!
Votre dernière diapositive devrait être votre diapositive finale. Remerciez les personnes pour leur participation et incluez un « prochaines étapes ». Pendant la clôture de votre présentation, récapitulez les points clefs abordés dans la session questions/réponses, noter les suivis nécessaires et distribuer les documentations pertinentes. Demandez à votre auditoire de vous contacter (assurez-vous que vos coordonnées soient sur la diapositive!) s’ils ont des questions ou voudraient approfondir le sujet.
Votre présentation exige-t-elle un suivi ? Par exemple, si vous présentiez à un nouveau client vos capacités dans l’espoir de gagner un business, cela exigera un suivi. Dans une telle situation, faites un suivi avec votre client le lendemain de la présentation – les remercient pour leur temps et demandent s’ils ont des questions ou exigent plus d’information. Donnez suite selon vos procédures de gestion. Si votre présentation était sur un projet et a exigé une décision, dans votre conclusion de la présentation, demander à l’auditoire quand une décision sera prise et assurez-vous de donner suite à ce moment-là. Votre suivi variera selon la situation et le but de la présentation. Si la présentation a pour objectif de partager de l’information et des connaissances avec l’auditoire(par exemple, en présentant à une conférence), vous pourriez simplement demander que l’auditoire vous contacte directement pour toutes questions ou nouvelles informations.
La prochaine fois vous avez une présentation – pensez à qui vous présentez à et quel est le but de la présentation. Planifiez ce que vous allez dire – créez un plan pour vous assurer que vous couvrez tous vos points dans le temps alloué. Meilleure la préparation, plus probablement vous obtiendrez un résultat réussi.
Vos idées ? Que faites-vous pour vous préparer pour des présentations ? Qu’avez-vous trouvé utile ?
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.
ObjectifL’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 :
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.
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.
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 progressifPour 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.
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 :
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.
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égociationPuisque 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.
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é.
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.
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.
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.
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.
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.
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:
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.
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.
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.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.
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.
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:
( 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, 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
Read the full article and let me know which other vital signs of projects should be watched.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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 1er 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.
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.
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é.
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?
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 1er 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.
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.
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é.
|
|||
|
|||
|
|||
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.
La documentation de projet est exigée pour réussir le projet. Elle est utilisée :
En sus de ces raisons, la documentation de projet offre des avantages supplémentaires aux chefs de projet, y compris :
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.
Copyright © 2010 Dhanasekaran Sivaraj
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.
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.
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.
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.
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 conclusionExcellent! 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.
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…
DantotsuPM.com 