I wrote the following article for Orange Business Live in English and French.
Beware not to confuse good idea with project: Ideas are immaterial and often vague but the « raison d’être » of the project does not suffer approximations…
Les bénéfices de la Documentation de Projet
Voici un article qui m’a interpellé sur le blog de Gina Abudi. Il est écrit par Dhanasekaran Sivaraj et sa version originale en anglais est lisible ici.
Documenter le projet ? ?
“Hummm…je préférerais passer ce temps sur d’autres activités plus importantes du projet.”
“Faisons-le après l’achèvement de toutes les activités du projet, pas tout de suite.”
“Je suis concentré sur la livraison du projet. La documentation peut attendre.”
“Je peux réaliser un projet de plus si je ne fais pas la documentation.”
Cela vous est familier ? Vous pouvez avoir entendu l’une ou toutes les excuses et les complaintes ci-dessus de beaucoup de chefs de projet, vous y compris. Ce sont des déclarations communément utilisées par les chefs de projet qui ne veulent pas faire un travail minutieux – ce qui signifie faire la documentation du projet. Si vous avez prononcé n’importe laquelle de ces phrases, il est temps de déposer une « Requête de Modification » pour changer votre perception de la documentation de projet.
La documentation de projet est un des secteurs les moins intéressants pour les chefs de projet car elle exige de nombreux efforts, mais est rarement applaudie par le chef. En réalité, cependant, la documentation de projet est un composant clef du management de projet et s’exécute du début à la fin de tout projet.
Examinons quelques points clefs à propos de la documentation de projet.
Pourquoi documenter ?
La documentation de projet est exigée pour réussir le projet. Elle est utilisée :
- Pour définir le contenu du projet et s’assurer de l’accord de toutes les parties prenantes et des membres de l’équipe. Ainsi, toute personne impliqué dans le projet partage la même compréhension des attentes, de quoi faire, quand le faire, etc.
- Pour établir une référence qui permettra de résoudre des différents et entre les parties prenantes si nécessaire.
- Pour garder une référence historique qui fournit des informations détaillées sur le projet et peut être utilisée réussir de futurs projets.
Les bénéfices de faire la documentation de projet
En sus de ces raisons, la documentation de projet offre des avantages supplémentaires aux chefs de projet, y compris :
- Une aide pour créer les Structures de Répartition de Travail (WBS) très détaillées qui aboutissent à l’élaboration de planning réalistes et réalisables.
- Une diminution des surprises et risques inutiles.
- Une aide pour prévoir l’avancement du projet pendant l’exécution et prendre des mesures proactives pour attaquer des défis.
- Une compréhension claire des pré-requis de projet pour toutes les parties prenantes.
Et…le boss vous verra, le chef de projet, comme une personne soucieuse des détails et minutieuse dans son travail. Ce qui augmente votre valeur dans l’organisation et fait de vous un chef de projet désirable sur tous les projets majeurs.
Résultat final – changez votre perception sur la documentation de projet et commencez à vous concentrer davantage sur ce secteur. Vous commencerez à en voir les bénéfices en un rien de temps et vous augmenterez la probabilité de succès de vos projets avec moins de stress pour vous et pour l’équipe de projet.
Copyright © 2010 Dhanasekaran Sivaraj
Comment vous faire repérer par un chasseur de tête
Lisez l’article intégral original en Anglais
Bonne nouvelle, selon nos collègues Britanniques, après deux années volatiles, il y aurait des signes de reprise du marché de l’emploi– et les chasseurs de têtes chercheraient des talents pour répondre à la demande.
Pour l’instant, je n’ai pas personnellement ressenti ce redémarrage mais j’espère sincèrement que cette reprise est en train de traverser la Manche sans encombre pendant que j’écris cet article.
Quelques conseils en 4 étapes de BNET pour bien vous positionner dans cette chasse aux talents.
prérequis: attester de 18 mois dans votre job pour montrer votre sérieux, construire une expérience, augmenter la visibilité professionnelle et élargir votre réseau de contacts utiles.
1. Peaufinez votre Curriculum Vitae (CV)
But : S’assurer que son Curriculum Vitae est varié et assez détaillé pour répondre aux attentes.
Votre CV reste votre carte d’entrée, mais les chasseurs de têtes cherchant des managers peuvent le regarder d’un œil plus critique parce qu’ils rechercheront des qualités et compétences spécifiques.
Essayez d’éviter les clichés ou assurez-vous si vous dites que vous êtes ‘proches du terrain’ ou ‘stratégiques et orientés résultats’ que vous pouvez le confirmer par des preuves et des exemples spécifiques.
Une trajectoire de carrière inhabituelle peut jouer en votre faveur si elle démontre une expérience riche et variée – postes à l’étranger, projets à l’extérieur de votre secteur principal et même volontariat montreront que vous avez du répondant.
Un gros handicap serait une suite rapide de changement de jobs. Les chasseurs de têtes aiment voir que vous êtes capables de vous investir dans un rôle.
2. Augmentez votre visibilité
But : Être reconnu comme un expert dans son industrie
Être reconnu de ses pairs serait la chose la plus importante sur laquelle se concentrer pour être remarqué par des chasseurs de têtes. Voici quelques idées :
– Identifiez les séminaires professionnels qui vous semblent pertinents et essayez d’y intervenir en tant que speaker.
– (Re-)Découvrez votre réseau d’anciens étudiants et collègues.
– Gérez votre Identité Numérique : Quelles informations s’affichent quand vous tapez votre nom dans un moteur de recherche ? Votre présence en ligne sera examinée par les chasseurs de têtes, donc cela vaut la peine de vérifier que votre page de LinkedIn (et/ou Viadeo) est à jour et que votre profil de Facebook passe le filtre.
– Rejoignez votre corps professionnel, comme, pour les chefs de projets, PMI ou Prince2 ou IPMA (ou les 3, mais attention aux tarifs).
– Soyez cités : dans les magazines et les sites web de votre industrie ou profession. Recherchez celui que l’on considère comme étant ‘la Bible’ de votre industrie.
3. Courtisez les chasseurs de têtes
But : Entrer dans le radar d’un professionnel de recherche de senior management
Devenez l’un des contacts de plusieurs chasseurs de tête pour leur donner des informations sur vos pairs. La capacité à proposer des candidats potentiels sur un poste témoigne de la qualité de votre propre réseau – et vous les aidez à faire leur travail. Tôt ou tard, ils vous considéreront pour un poste parce que votre nom est toujours le premier qui leur vient à l’esprit.
Évitez les appels « à froid ». Essayez d’être introduit par un ami. Cela facilitera le premier contact.
Une fois que vous avez réussi à faire en sorte que votre chasseur de tête sache que vous existez, vous pouvez être invités pour une réunion en face à face, pour qu’ils puissent déterminer si vous méritez votre réputation.
4. Affûtez votre technique d’entretien
But : S’assurer que la première impression est durable
Vous n’aurez pas de deuxième occasion de faire une bonne première impression. Entraînez-vous à présenter vos compétences et votre expérience et peaufinez votre marque personnelle.
Qu’on le veuille ou pas, la robe importe aussi : Soignez votre apparence.
Écoutez soigneusement ce que l’on vous a demandé et allez au bout de votre pensée dans votre tête avant de répondre. Puis, répondez précisément – comme un cadre supérieur à son bureau exécutif.
Faites quelques recherches sur le chasseur de tête qui vous interviewe – vérifiez le site Web de sa société ou son profil sur les médias sociaux. Il est toujours flatteur qu’un candidat ait fait cet effort.
En conclusion
Excellent! Vous avez été remarqué; vous avez remis un CV impressionnant et avez passé avec succès l’entretien initial; ne vous congratulez pas trop vite. Le vrai boulot commencera quand vous serez présenté pour ce rôle important que vous recherchiez.
Remarques personnelles: J’ajouterais de ne pas oublier que ce job dont vous rêvez se trouve peut-être dans votre propre société. Donc, attachez-vous à appliquer les conseils ci-dessus aux potentiels recruteurs au sein de votre entreprise. Pour être bon face aux chasseurs de têtes, soyez bon dans votre job : la confiance en soi est un atout précieux que ces professionnels perçoivent dès les premiers instants.
Votre sponsor est-il aux abonnés absents?
Dans l’armée, si un soldat ou tout autre militaire quitte son poste sans autorisation, il ou elle est considéré « Absent Sans Permission ». Un soldat manquant laisse un vide — qui pourrait impacter négativement la mission. Chaque personne impliquée dans un projet, y compris le sponsor, a un rôle à jouer dans l’atteinte des objectifs du projet.
Tout plan de travail devrait mettre en évidence la participation des parties prenantes et du sponsor. Voici quelques suggestions pour garder les sponsors impliqués et participatifs :
1. Prévoyez des réunions régulières (généralement mensuellement) avec les sponsors, les membres de l’équipe et les autres parties prenantes importantes: Cela peut être l’opportunité d’une « rapide » mise à jour sur le statut; mais ce qui est plus important, c’est d’utiliser ce temps pour renforcer la valeur et la signification du projet en termes de business et d’engagement des sponsors à aider l’équipe.
2. Éduquez les sponsors sur leur rôle en tant que membres de l’équipe : les sponsors ont un rôle significatif d’avocats du projet auprès du comité de direction de façon à bien communiquer avec les parties prenantes et fournir la visibilité au management exécutif.
3. Ne négligez pas les opportunités impromptues de tête-à-tête avec les sponsors du projet : Assurez-vous que vos sponsors sont enclins à avoir des réunions informelles occasionnelles quand nécessaire. Il est important de cultiver la relation avec les sponsors — vos succès impactent leur succès et vice versa.
Garder les sponsors impliqués fait souvent la différence entre le projet qui réussit et celui qui échoue. Les outils de management de projet peuvent faciliter la communication avec les parties prenantes et les sponsors, mais indépendamment de votre manière de travailler, permettre aux sponsors de projet d’être aux abonnés absents n’est jamais une bonne idée.
Alors, comment empêchez-vous vos sponsors de « déserter » ?
Votre sponsor est-il aux abonnés absents?
http://blogs.attask.com/blog/strategic-project-management/0/0/is-your-project-sponsor-awol
Par Ty Kiisel
Dans l’armée, si un soldat ou tout autre militaire quitte son poste sans autorisation, il ou elle est considéré « Absent Sans Permission ». Un soldat manquant laisse un vide — qui pourrait impacter négativement la mission. Chaque personne impliquée dans un projet, y compris le sponsor, a un rôle à jouer dans l’atteinte des objectifs du projet.
Tout plan de travail devrait mettre en évidence la participation des parties prenantes et du sponsor. Voici quelques suggestions pour garder les sponsors impliqués et participatifs :
1. Prévoyez des réunions régulières (généralement mensuellement) avec les sponsors, les membres de l’équipe et les autres parties prenantes importantes: Cela peut être l’opportunité d’une « rapide » mise à jour sur le statut; mais ce qui est plus important, c’est d’utiliser ce temps pour renforcer la valeur et la signification du projet en termes de business et d’engagement des sponsors à aider l’équipe.
2. Éduquez les sponsors sur leur rôle en tant que membres de l’équipe : les sponsors ont un rôle significatif d’avocats du projet auprès du comité de direction de façon à bien communiquer avec les parties prenantes et fournir la visibilité au management exécutif.
3. Ne négligez pas les opportunités impromptues de tête-à-tête avec les sponsors du projet : Assurez-vous que vos sponsors sont enclins à avoir des réunions informelles occasionnelles quand nécessaire. Il est important de cultiver la relation avec les sponsors — vos succès impactent leur succès et vice versa.
Garder les sponsors impliqués fait souvent la différence entre le projet qui réussit et celui qui échoue. Les outils de management de projet peuvent faciliter la communication avec les parties prenantes et les sponsors, mais indépendamment de votre manière de travailler, permettre aux sponsors de projet d’être aux abonnés absents n’est jamais une bonne idée.
Alors, comment empêchez-vous vos sponsors de projet de « s’absenter sans permission » ?
10 minutes on your project with the big boss
I read an article written by Ty Kiisel that made me think about key things to have in mind when you get a chance to present your project to one or more senior executives.
His article is entitled « When Presenting to Stakeholders—You’ve Only Got About a Minute ».
Like Ty, I observed that a common trait of senior executives is that they’re often fighting for time. As a result, their attention span is quite limited and you better not waste the opportunity to address them when it arises. Having said that, everyone’s time is precious. Time is something we get in very limited quantity when we come to birth. So, be concise, adapt your language to the other party, tease their interest, be specific…
All 10 tips proposed by Ty are certainly worth the lecture. I’d retain 3 as really key in my experience when it comes to presenting to senior executives and I would add one that I could not find in the list.
1. Big picture (personal addition): Remind them of the overall context of the project or issue that you want to discuss. Do not assume that they recall who you are or what your project is about. They have many things to juggle. So, start from the basics of how your project supports one or more of their strategic objectives for the company before diving into any detail. Then, provide a rapid overview of the project scope, investments, duration and key milestones. Position where you are at present against these.
2. Keep it simple: Be straightforward. Expose the facts and why their involvement is required. Don’t overwhelm them with information, be concise, do not use jargon. Doing otherwise would be a waste of time and they’ll think that you can’t synthesize a situation effectively or can’t express yourself intelligibly.
3. Always offer a solution: Offer a couple of options for a solution (but no more than 2). As pointed by Ty, there is no point in bringing up problems without potential solutions. They can decide between two solutions but it is your job to come up with well articulated options that highlight pros, cons, costs and project impact.
4. Specify the actions required of them: What exactly do you need from them? A memo or phone call to unlock a situation, more money, more time, more resources, arbitration, prioritization decision…
When Presenting to Stakeholders—You’ve Only Got About a Minute
I read an article written by that made me think about key things to have in mind when you get a chance to present your project to one or more senior executives. His article is entitled « When Presenting to Stakeholders—You’ve Only Got About a Minute ». (http://blogs.attask.com/blog/strategic-project-management/0/0/when-presenting-to-stakeholdersyouve-only-got-about-a-minute )
Ty is very correct that a common trait I observed with senior executives is that they’re often fighting for time. So, their attention span is quite limited and you need not to waste the opportunity to address them when you have one. Having said that, everyone’s time is precious. Time is something we get in very limited quantity when we come to birth. So, be concise, adapt your language to the other party, tease their interest, be specific…
All 10 tips proposed by Ty are certainly interesting. I’d retain 3 as really key in my experience when it comes to presenting to senior executives and I would add one that I could not find in the list.
- Big picture (personal addition): Remind them of the overall context of the project or issue that you want to discuss with them. Do not assume that they recall who you are or what your project is about. They have many things to juggle. So, start from the outskirts of how your project supports one or more of their strategic objectives for the company before diving into any detail. Then, the project scope, investment, duration and key milestones. Position where you are at present against these.
- Keep it simple: Expose the facts and why their involvement is required in straightforward terms. Don’t overwhelm them with information, be concise. It would be a waste of time and they’ll think that can’t synthesize a situation effectively.
- Always offer a solution: Or a couple of options for a solution but no more than 2. There is no point in bringing up problems without potential solutions. They can decide between two solutions but it is your job to come up with well articulated proposals that highlight pros, cons, costs and project impact.
- Specify the actions required of them: What exactly do you need from them? A memo or phone call to unlock a situation, more money, more time, more resources, arbitration, prioritization decision…
10 minutes avec le grand chef pour parler de votre projet
J’ai lu un article de Ty Kiisel qui m’a fait penser aux quelques points à garder à l’esprit lorsque l’on a opportunité de présenter son projet à un ou plusieurs dirigeants.
L’article de Ty s’intitule: « When Presenting to Stakeholders—You’ve Only Got About a Minute ».
Comme Ty, j’ai pu apprécié que l’un des points communs des dirigeants est qu’ils ont très peu de temps. Aussi, leur temps d’attention pour notre projet est très limité et il vaut mieux ne pas gâcher l’opportunité de s’adresser directement à eux si elle se présente. Cela dit, le temps de tout un chacun est précieux. Le temps est une denrée qui nous est donnée en quantité limitée à notre naissance. Donc, soyons concis, adaptons notre propos à notre interlocuteur, attisons son intérêt, soyons précis…
Les 10 points proposés par Ty méritent d’être lus. J’en retiendrais 3 qui sont réellement primordiaux selon mon expérience et j’en ajouterais un que je n’ai pas trouvé dans la liste:
1. Vue d’ensemble (mon addition personnelle): Rappelons le contexte dans lequel s’insère notre projet. N’assumons pas qu’ils se souviennent de qui nous sommes ou l’objet de notre projet. Ils ont beaucoup de choses à gérer en parallèle. Démarrons par la manière dont notre projet supporte un ou plusieurs de leurs objectifs stratégiques avant d’entrer dans les détails. Poursuivons ensuite par un résumé du contenu, coûts, délais, et jalons majeurs du projet. Expliquons où nous en sommes par rapport à ceux-ci.
2. Faisons simple: Soyons directs. Exposons les faits et pourquoi leur implication est nécessaire. Ne les inondons pas d’informations, soyons concis, n’utilisons pas de jargon. Procéder autrement serait un gaspillage de temps et ils penseraient que nous sommes incapables de faire une synthèse efficace et de nous exprimer clairement.
3. Proposons des solutions: Offrons une ou deux options (mais pas plus). Comme Ty l’indique dans son article, il ne nous servirait à rien de présenter des problèmes sans proposition de solution. Ils savent décider entre deux solutions mais c’est notre responsabilité de présenter des options cohérentes et documentées qui mettent en évidence avantages, inconvénients, coûts et impacts sur le projet.
4. Soyons spécifiques sur ce que nous attendons d’eux: Un mémo ou un coup de fil pour débloquer une situation, plus d’argent, de temps, de ressources, un arbitrage, une décision sur les priorités…
B.A.-BA : répondre aux résistances
Dans un article précédent, j’ai décrit le B.A.-BA: pour conduire des entretiens téléphoniques efficaces. Dans cet article, je voudrais me concentrer sur quelques éléments essentiels pour répondre aux résistances pendant des appels téléphoniques ou des réunions, particulièrement si vous devez vendre un projet ou une idée. De nouveau, rien de neuf sous le soleil pour les chefs de projet expérimentés ou les professionnels de la vente. Mais, ce qui va sans dire, va encore mieux en le disant.
J’ai appris qu’il y a essentiellement trois types différents de résistance qui doivent être reconnus et gérés : Perception incorrecte, Scepticisme et Problème. En réalité, la manière de répondre dans ces trois situations n’est pas si différente mais voyons cela au cas pas cas :
1. Perception incorrecte
Avoir une perception incorrecte c’est soit percevoir inexactement ou bien mal comprendre. Vous vous trouvez dans une situation où, après avoir exposé votre topo, vous avez écouté activement votre interlocuteur. Vous remarquez que votre message n’est pas compris. Il peut y avoir beaucoup de raisons à cela : la manière dont vous vous êtes exprimé; des idées préconçues ou un manque d’écoute de la part de votre interlocuteur; un sujet trop complexe pour être compris du premier coup; un domaine qui exige des connaissances préalables que l’autre personne peut ne pas posséder … Ce qui est nécessaire dans cette situation c’est tout d’abord d’établir qu’il y a une mauvaise perception, de fournir ensuite une clarification et de conclure par une nouvelle écoute et un questionnement pour confirmer l’accord.
- Établir qu’il y une mauvaise perception : prouvez, en répétant autant que possible les mots utilisés par la personne, que vous avez identifié une perception incorrecte. Précisez que la faute est la vôtre. Cette mauvaise perception ou ce malentendu est survenu parce que vous n’avez pas encore été capable de transmettre votre message assez clairement pour convaincre la personne.
Par exemple : «je vous entends dire que vous comprenez que ce projet durera 2 ans et exigera 10 membres du personnel de l’entreprise. Je vois que je n’ai pas été clair dans mes explications et je voudrais clarifier ce point spécifique.»
Fournissez la clarification sur l’élément qui n’a pas été bien compris.
Dans notre exemple : «le projet durera en effet 2 ans et nécessitera 10 ressources avec la portée actuellement définie. Cependant, une option présentée est de composer l’équipe à 50/50 entre internes et externes. De plus, une deuxième option est de réduire la portée initiale pour obtenir la plus grande partie possible des bénéfices sur une période plus courte, si vous pensez que c’est souhaitable pour l’entreprise.»
- Et concluez avec une nouvelle écoute et des questions pour confirmer l’accord.
Dans notre exemple : «j’ai vu que vous avez hoché la tête quand j’ai clarifié que nous pourrions pourvoir le projet avec 50 % de ressources externes. Sommes-nous d’accord que cette option est une bonne approche pour construire le projet ?»
2. Scepticisme
Le scepticisme s’apparente très souvent à des doutes et un désir de suspendre son jugement par rapport à de nouvelles informations qui ne sont pas très bien supportées par l’argument ou l’évidence présenté. Quand vous remarquez que les informations que vous avez fournies ne sont pas bien acceptées et que ce n’est pas en raison d’un malentendu, mais plutôt du scepticisme, vous êtes dans une situation qui exige l’assurance ou la réassurance. Donc, reconnaissez le scepticisme, rassurez et concluez par une nouvelle écoute et des questions pour confirmer l’accord.
- Reconnaissez le scepticisme : vous anticiperez souvent cette réaction potentielle en passant en revue votre proposition ou argumentaire. Vous vous mettez vraiment dans les chaussures de votre homologue pendant un moment et essayez de voir depuis sa perspective ce qui pourrait être douteux dans votre projet ou idée. Dans certains cas, vous pouvez tout simplement vous remémorez que, lorsque vous n’étiez pas encore familier avec le projet, vous aviez également eu des doutes . Utilisez ceux-ci pour montrer que vous comprenez le scepticisme de votre interlocuteur.
Par exemple : « je vois que vous semblez avoir des doutes sur les 2 ans de durée et 240 homme mois d’effort. Très sincèrement, c’était également ma première réaction quand j’ai reçu ces évaluations. »
- Rassurez sur le sujet qui génère du scepticisme. Si vous le pouvez, fournissez davantage de faits et preuves sur votre argumentaire. Des benchmarks ou des études, des chiffres de projets antérieurs, des références (particulièrement de personnes que votre homologue connaît bien), des précédents, des statistiques, … sont autant de sources que vous pouvez utiliser pour rassurer la personne sur le sujet.
Dans notre exemple : «Aussi, j’ai questionné l’équipe pour comprendre les détails. Et, ils ont été capables de me montrer les chiffres d’un projet précédent de complexité et portée semblables. Il avait coûté 360mm avec 12 ressources sur 2 ans et demi. Grâce à cette expérience, ils ont été capables de réduire la durée de notre projet à 2 ans et la taille d’équipe à 10 ressources au lieu de 12. Une amélioration de 30 % et avec une équipe qui a déjà réalisé un projet semblable.»
- Et concluez avec une nouvelle session d’écoute et de questionnement pour accord.
Dans notre exemple : «vous avez semblé être sur la même longueur d’ondes que moi quand j’ai exposé la façon dont les évaluations ont été construites. Êtes-vous plus à l’aise avec cet aspect du projet ?»
3. Problème
«J’ai un problème …» est la méthode traditionnelle de remonter une préoccupation, un souci, lors d’une réunion. C’est une déclaration très puissante et qui, si elle n’est pas réglée, peut tout stopper. Si votre contrepartie ne l’exprime pas ouvertement, mais vous pouvez voir qu’il y a un problème réel pour lui ou elle, posez la question: «À votre avis, quel pourrait-être le problème-clé ou la préoccupation que le projet devrait adresser en priorité ?». De nouveau, ce qui est exigé dans cette situation est en premier lieu de reconnaître qu’il y a un problème, ensuite réaffirmer les points forts de votre proposition, chercher une résolution et conclure par une nouvelle écoute et des questions pour confirmer l’accord.
- Reconnaissez le problème : assurez-vous que vous comprenez précisément le souci. Est-ce le coût, les délais, le contenu, l’approche, la dotation en personnel, les compétences, les conditions de paiement ? Prouvez, en réutilisant autant que possible les mots de la personne, que vous avez vraiment compris où se situe le problème.
Par exemple : «je vous entends mentionner comme un problème le fait que le projet durera 2 ans et exigera 10 membres du personnel interne. Et que la durée est une réelle préoccupation ou un point de blocage pour vous parce que votre fenêtre d’opportunité pour lancer ces nouveaux services sur le marché n’est que de 18 mois.»
- Réaffirmez les points forts de votre proposition et utilisez des accords établis précédemment pour renforcer les bénéfices escomptés. Réitérez l’équation besoins/bénéfices du projet.
Dans notre exemple : «Nous avons établi ensemble que ce nouveau projet est absolument nécessaire pour permettre à la société de livrer ces nouveaux services. Des études préalables ont établi que des modifications aux systèmes existants coûteraient davantage et demanderaient plus de temps. De plus, nous sommes d’accord sur la portée du projet en termes de contenu et d’évaluation des charges. Ce projet permettra aux nouveaux services d’être développés et exploités efficacement.»
- Cherchez la résolution avec votre contrepartie pour éliminer ou contourner le problème.
Dans notre exemple : Ce projet durera en effet 2 ans avec 10 ressources pour la portée actuellement définie. Cependant, une option que nous avons examinée est de réduire la durée en amenant des ressources supplémentaires pour exécuter certaines tâches en parallèle plutôt que séquentiellement. D’autre part, nous avons également l’option mentionnée précédemment de réduire la portée initiale pour nous concentrer sur les fonctions les plus critiques. Celles qui permettront de répondre à la majorité des besoins sous 18 mois, avec quelques adaptations de processus. Puis, nous livrerons une version qui couvrira la totalité du périmètre un peu plus tard.»
- Et concluez avec une nouvelle écoute et questionnement pour accord.
Dans notre exemple : «j’ai vu que vous avez été sensible à l’option d’ajouter du personnel externe sur le projet. Sommes-nous d’accord que ce serait une bonne approche pour avancer sur le projet ?»
Bien sûr, les chefs de projet ne sont pas des commerciaux professionnels, mais connaître quelque-unes des ficelles pour mieux répondre aux résistances pendant des réunions est une compétence fort utile dans nos vies professionnelle et privée.
back to basics: responding to resistance
In a previous post, I wrote about the basics for running an effective call. In this article, I’d like to focus on some of the basics for responding to resistance during calls or meetings, especially when you’re selling a project or an idea. Again, this is certainly nothing new for experienced PMs or sales professionals. But what goes well without saying, goes even better when you say it.
I learned that there are essentially three different types of resistance that need to be recognized and managed: Misperception, Skepticism and Concern. Actually, the way to respond is not so different but let’s see the three cases:
1. Misperception
To misperceive is to perceive incorrectly or misunderstand. You are in a situation where you have exposed your point and then listened actively to your counterpart. And you notice that the message you are trying to get through is not understood. This could be due to many reasons: the way you expressed it; preconceived ideas or lack of listening on the other side; too complex to be understood in one shot; requiring prerequisite knowledge that the other person may not have… What is required in this situation is first of all to acknowledge the misperception, then provide clarification and conclude with listening again and probing for acceptance.
- acknowledge the misperception: prove by repeating as much as possible the words of the person that you acknowledge the fact that there is a misperception. Make it clear that the fault is yours. The misperception or misunderstanding has happened because you have not been able yet to convey your message clearly enough to convince the person.
For example: « I hear you say that you understand that this project will last 2 years and require 10 internal staff members. I have not been clear in my explanations and I’d like to clarify this very specific point. »
provide clarification on the piece that has not been well understood.
In our example: « The project would indeed last 2 years and 10 resources with the currently defined scope. However, one option I presented is to resource with a 50/50 split between internal and external. Also, you have the second option I mentioned of reducing the initial scope to get the bulk of the benefits in a shorter timeframe if you believe this is feasible. »
- and conclude with listening again and probing for acceptance.
In our example: « I saw you nod your head when I clarified that we could staff the project with 50% of external resources. Are we in agreement that this option is a good approach to build upon for the project? »
2. Skepticism
Skepticism very often means doubts and desire to suspend judgment on new information that is not very well supported by argument or evidence. When you notice that the information you provided is not well accepted and that it is not due to a misunderstanding but rather skepticism, you are in a situation that requires assurance or reassurance. I.e. acknowledge the skepticism, then provide assurance and conclude with listening again and probing for acceptance.
- acknowledge the skepticism: you will often have anticipated this potential reaction as you reviewed your proposal or speech. You did put yourself in the shoes of your counterpart for a moment and tried to see from his eyes what could be doubtful with your project or idea you’re selling. In other instances, you can recall the times when you were not familiar with the project or idea and potentially shared similar doubts. Use these to show that you understand the skepticism of your counterpart.
For example: « I see that you seem to have doubts with the 2 years and 240 man month effort. To be honest, it was also my first reaction when I saw these estimates.«
- provide assurance on the piece that is generating skepticism. If you can, provide more facts and evidence that the information you provided is certain. Industry benchmarks or studies, figures from prior projects, references (especially from persons your counterpart knows well), track record, statistics,… are as many sources you may want to use to assure the person on the topic.
In our example: « So, I challenged the team to understand the details. And, they were able to show me the figures from a prior project of similar complexity and scope that had cost 360mm with 12 resources over 2.5 Years. Thanks to that earlier experience, they were able to reduce the duration of our project to 2 years and the team size to 10 resources instead of 12. A 30% improvement with a team that has already undertaken a similar challenge! »
- and conclude with listening again and probing for acceptance.
In our example: « You appeared to be in tune with me when I exposed the way the estimates were built. Are you more comfortable with this aspect of the project? »
3. Concerns
« I have a concern… » is the traditional method of bringing up an issue to a meeting. It is a very strong statement and if unsettled a concern about something will stop it from being done. If your counterpart is not expressing his concerns openly but you can tell that there is a real issue for him or her that is not being addressed, ask the question. « In your opinion, what is the key issue or concern with the proposed project that we shall address? ». Again, what is required in this situation is first to acknowledge the concern, then to reaffirm the strong points of your proposal, seek resolution and conclude with listening again and probing for acceptance.
- acknowledge the concern: make sure that you understand the exact concern. Is it cost, time, contents, approach, staffing, skills, payment terms? Prove by repeating as much as possible the words of the person that you have really understood where the concern is.
For example: « I hear you mention as a concern the fact that the project will last 2 years and require 10 internal staff members. And that the duration is a real issue for you because your window of opportunity is 18 months to bring the new services to the market. »
- reaffirm the strong points of your proposal and use established agreements to reinforce the foreseen benefits. Restate the needs/benefits equation for the project.
In our example: « This new project is absolutely required to enable the company to deliver these new services and earlier studies have established that amendments to existing solutions would cost more and take longer. Additionally, we are in agreement on the scope of the project in terms of contents and resources required to achieve it. The project will enable the new services to be developed and operated efficiently. »
seek resolution looking for solutions with your counterpart that would remove his concerns.
In our example: « The project will indeed last 2 years and 10 resources with the currently defined scope. However, an option we looked at is to reduce the duration by bringing extra resources to run in parallel some tasks that are currently planned sequentially. Also, we have the option I mentioned earlier to reduce the initial scope to focus on very critical functionality that will get you the bulk of the benefits in 18 months with some manual processes while developing the full functionality in the next release. »
- and conclude with listening again and probing for acceptance.
In our example: « I saw you nod your head when we rediscussed the option to add external staff the project. Are we in agreement that this is a good approach to move forward on the project? »
Of course, PMs are not professional sales people, but mastering the basics for responding to resistance during calls or meetings is a very useful asset in our professional and personal life.
les leçons apprises, cela n’intéresse personne !
C’est sous ce titre volontairement provocateur que j’ai écrit un article dans lequel je propose une approche pour partager efficacement les expériences de Management de projet.
Pour progresser, les erreurs passées ne seront pas répétées alors que les succès deviendront une partie intégrante de notre manière de travailler. Cela semble tout à fait raisonnable, je l’espère. Cependant, peu d’entre nous y dédient l’attention requises. Voici une proposition pour essayer de changer cette situation.
Avez-vous d’autres approches réussies à proposer ?
B.A.-BA – conduire des entretiens téléphoniques efficaces
Je suis souvent étonné du manque apparent de professionnalisme dont font preuve certaines personnes dans leur manière de conduire des entretiens téléphoniques. En particulier lorsqu’ils ont lieu avec des clients, prospects, commanditaires, ou des niveaux de direction.
Je me demande si certaines des bases que nous avons appris très tôt dans notre vie professionnelle n’ont pas été oubliées. Dans mon cas, cet apprentissage s’est déroulé alors que les téléphones portables étaient « portatifs », la messagerie instantanée à inventer, sans parler des gazouillis de Twitter… C’était également une époque où les coûts de télécommunication étaient beaucoup plus élevés que de nos jours. Ceci explique peu-être pourquoi certaines de ces bases pourraient vous paraître dépassées. Pourtant, je les trouve encore extrêmement d’actualité dans mes communications téléphoniques. Je considère qu’elles démontrent un respect envers mon interlocuteur et le temps qu’il ou elle me consacre.
Vu le temps que les chefs de projet passent sur ce type de communication, J’ai pensé qu’il pourrait être utile de partager la structure que j’essaie toujours de suivre. C’est en fait très simple:
1. saluer la personne, se présenter et créer une atmosphère: si c’est une personne avec laquelle je parle souvent et connais assez bien, il est facile de rompre la glace avec quelques mots sur un sujet d’intérêt commun. Sinon, je reprends mes notes d’interactions passées ou je fais une rapide recherche Google , LinkedIn ou Viadeo pour trouver une accroche. Et, si la personne est référencée sur votre annuaire d’entreprise intranet, lisez sa fiche et regardez sa photo pour mettre un visage sur le nom.
2. positionner: confirmer le pourquoi de l’entretien et ses objectifs.
3. confirmer la durée: valider l’heure à laquelle l’entretien devra prendre fin et ne pas en déroger sauf sur demande de la personne appelée.
4. communiquer le plan de l’entretien: lister les sujets que vous aimeriez couvrir pendant cette session. Cela permet de se repérer pendant l’appel, cela évite les surprises, et aide à structurer l’appel et à gérer le temps.
5. écouter, valider l’accord: confirmer avec la personne que le plan proposé lui convient et demander si d’autres sujets devraient être ajoutés (ou certains enlevés).
6. dérouler l’appel en suivant le plan proposé et en s’assurant sur chaque point d’une compréhension commune par des questions de vérification et de validation.
7. faire un résumé de l’appel: Cette étape me permet de vérifier mes notes; de m’assurer que tous les sujets ont été couverts et si cela n’est pas le cas prévoir un appel ultérieur; et, d’expliciter ma compréhension de ce qui a été dit.
8. écouter, valider l’accord: Prendre le temps de vérifier que ma compréhension est correcte et que je n’ai rien oublié.
9. prendre note des actions: Il est temps de vérifier que nous avons bien un jeu commun d’actions agréées.
10. écouter, valider l’approbation: Pour confirmer nos engagements respectifs sur ces actions.
11. remercier la personne de son temps et contributions et pour les actions qu’elle a accepté de mener.
Ensuite, je m’efforce de ne jamais oublier de faire un suivi des actions sur lesquelles nous sommes d’accord.
back to basics for running effective calls
I’m often amazed by the apparent lack of professionalism some people demonstrate in running calls, especially with sponsors, customers, prospects, senior management…
I wonder if some of the basics we learned early in our careers have not been forgotten. In my case, I learned these when cell phones, instant messaging, tweets… did not yet exist, and also at a time when telecoms costs were much more significant than Today. This may explain why some of these basics may seem a bit outdated. However, I personally still find them very very relevant in my day to day communications. I think that they also are a display of my respect towards the person I’m calling and for the time he or she dedicates to discuss with me.
Given time that Project Managers spend on calls, I thought that it could be useful to share how I always try to structure to be in good position. It is quite simple:
1. greet, introduce and relate: if I speak frequently with the person, it is quite simple to find « small talk » topics to break the ice. If I do not know the person very well, I’ll try to refer back to my notes from prior interactions, or perform a quick Google or LinkedIn search. And, if the person is referenced on the intranet directory, look at her information and picture to put a face on the name.
2. position: confirm the purpose and objectives of the call
3. confirm timing: confirm until when you have for this call and then do not overrun unless requested by the person you call
4. communicate plan: provide a rapid outline of the topics you’d like to cover during the call. It avoids surprises, it helps to structure the call and also it gives a way to check progress versus time allotted for the call.
5. listen/probe for agreement: confirm with the person that this plan is OK and ask if topics should be added or removed in their opinion.
6. 
run the call following the above plan and constantly probing, listening and confirming my/our mutual understanding
7. summarize the call: This step allows me to check my notes, verify that all topics we wanted to cover have been. And, if it’s not the case agree to a follow up call. Repeat my understanding of what has been said.
8. listen/probe for agreement: Take the time to check that my understanding is correct and verify that I haven’t missed any point.
9. propose actions: Now it’s time to double check that we have a common set of agreed actions.
10. listen/probe for commitment: This is to confirm our respective commitments to conduct the above actions
11. thank the person for their time and contributions and for accepting some of the above actions.
Then, I try to never forget to follow through on the actions we agreed.
Un nouveau PMI REP (Registered Education Provider) en France
Ayant le plaisir de bien connaître une partie des ressources expérimentées de cette jeune et dynamique entreprise Meta Projets, je me permets de vous inviter à les contacter pour plus d’infos si vous avez des besoins en formation, conseil et-ou accompagnement de vos projets.
lessons learned, nobody cares !
I posted on Orange Business live the following article about a proposed framework to share lessons learned in the Project Management area.
In order to progress, past errors shall not repeat while past successes must become an integral part of our way of working. This sounds quite reasonable I hope. However, we often do not allot sufficient quality time to learn from past experience. How can we improve in this Experience Sharing exercise?
20+ questions for a « lessons learned » session at the end of your project
Over time, I gathered from various sources a number of questions that I find appropriate to consider with the team at the end of a project.
Governance and Communication
1. What did the project committee do well that could be reused on future projects?
2. Where could it have done a better job?
3. How well were the organizations and users informed about the project?
4. Were appropriate communication channels and media used?
5. Did various audiences receive appropriate, timely information about the project?
6. Was too much or too little information communicated at any stage?
Change Management
7. What changes were requested or introduced during the project?
8. Did the changes prove to be valuable, e.g., increased benefits, lower overall costs?
9. Were any project objectives compromised through the introduction of a change?
Risk Management
10. How many anticipated risks materialized, and how were they managed?
11. How many unanticipated risks materialized, and how were they managed?
12. What risks were well managed, and which could have been better handled?
13. Did we spend the appropriate time on risk management?
Time Management
14. Was the project delivered on time? If not, please provide reasons with examples and any mitigation factors.
15. Was project governance timely established?
16. Did the governance help make effective, timely decisions for the project’s benefit?
17. Is everything in place to rip the benefits as soon as possible?
Finance Management
18. Has the project completed a review of its business case at the end of the implementation?
19. How do the actual project costs compare to the original estimates?
20. What did cost more than budgeted, what did cost less, and why?
21. How could costs be reduced on future, similar projects without compromising success?
22. Were the benefits reached on time with appropriate business ownership?
Quality Management
23. Has the project met its quality objectives?
Project Support tools
24. How well or badly were the support tools for the project assisting you and how well did they work?
Une bonne vingtaine de questions à considérer pour vos sessions « Leçons apprises » de fin de projet
Au fil du temps, j’ai accumulé de diverses sources pas mal de questions qu’il me semble utiles de se poser avec l’équipe en fin de projet.
Gouvernance et Communication
1. Qu’est-ce que le comité de projet a réussi qui pourrait être passé aux futurs comités de projet ?
2. Où aurait-il pu faire mieux ?
3. Comment était le niveau d’information du business et des communautés d’utilisateurs ?
4. Les canaux de communication et médias déployés étaient-ils appropriés?
5. Les diverses audiences ont-elles reçu des informations appropriées, au bon moment sur le projet ?
6. Est-ce que trop ou trop peu d’informations ont été communiquées à un moment donné ?
Gestion des Changements
7. Quels changements ont été demandés ou introduit pendant le projet ?
8. Les changements ont-ils démontré la valeur, par exemple, des bénéfices accrus, des réductions de dépenses globales ? Si non, merci de donner des exemples concrets.
9. Quels objectifs du projet ont été compromis par l’introduction d’un changement ?
Gestion des risques
10. Combien de risques prévus se sont réalisés et comment ont-ils été managés ? Si non, merci de donner des exemples concrets.
11. Combien de risques imprévus se sont réalisés et comment ont-ils été managés?
12. Quels risques ont été bien gérés et lesquels pourraient avoir été mieux gérés ?
13. Avons-nous passé le temps approprié sur la gestion des risques ?
Livraison dans les Temps
14. Le projet a-t-il été livré à l’heure ? Si non, merci de donner des raisons à partir d’exemples concrets.
15. La gouvernance de projet a-t-elle été établie au bon moment ?
16. L’équipe de gouvernance a-t-elle pris des décisions efficaces, opportunes pour le bénéfice du projet et du business ?
17. Tout est-il en place pour réaliser les bénéfices le plus tôt possible ?
Gestion Financière
18. Le projet a-t-il complété sa revue de business case de fin de projet?
19. Comment les dépenses effectives du projet se comparent-elles aux évaluations de pré-projet ?
20. Qu’est-ce qui a coûté plus que budgétisé ou bien moins et pourquoi ?
21. Comment les dépenses pourraient-elles être réduites à l’avenir sur des projets semblables sans mettre en péril les objectifs de projet ?
22. Est-ce que le plan de réalisation des bénéfices a été atteint dans les temps avec un bon engagement business?
Management de la qualité
23. Le projet a-t-il atteint ses objectifs de qualité ?
Outils de support du Project
24. Les outils de support du projet ont-ils bien supporté votre travail et ont-ils bien marché ?
Quelles questions ajouteriez-vous à cette liste?
Cours sur le web de Gestion de Projets – Ecole Centrale de Lille
Rémi Bachelet, Maître de conférences à Ecole Centrale de Lille, a mis en ligne des cours de gestion de projet, en micro-apprentissage (microlearning) en diapositives animées, vidéo, ppt, pdf…
a win-win approach to project managers development
As president of PMI France-Sud, I was often told by different companies: « We’re not very good at Project Management! » And my comment back to them was: « So, what are you going to do about it? ».
Indeed, some companies have poor project management capabilities. But are they just « getting what they deserve » for the lack of attention they pay to this tough profession? Developing a robust project management capability is an obligation in most companies nowadays.
De nombreuses méthodes de management de projet – Many PM methodologies
Suite à une demande sur un forum LinkedIn, Marc Bonnemains, partage avec nous une liste de méthodes qui sont utilisées dans différents contextes métiers et pays à travers le monde.
Nous avons différentes méthodes de gestion de projet à ne pas confondre avec un corpus de connaissance comme le PMBOK, bien sûr.
- Prince2
- IPMA Compétence base line
- APM Body of knowledge
- GAPPS – Global Alliance for Project Performance Standards
- La conduite de projets à l’IN2P3
- HERMES – La méthode suisse de conduite de projets
- Japanese Project Management – Project and Program Management for Enterprise Innovation (P2M)
- IEEE Software Engineering Standards
- ADePT Methodology (nouvelle approche)
- Il existe aussi des méthodes de gestion de projet pour ONG – COTA
- Peace Corps – Peace Corps Programming and Training Manual
- SCALPS : Guide des projets scientifiques du CNES – Support méthodologique commun, il est destiné aux laboratoires, entreprises, industriels et aux responsables du CNES chargés du développement de produits. Il a pour objectif de leur apporter un soutien dans la conduite de projet, et de renforcer leur autonomie envers les agences spatiales.
- Référentiel QUAPITAL-HERMES V1.2 – Issue de la méthode HERMES créée par l’Unité de Stratégie Informatique de la Confédération suisse (USIC), le référentiel QUAPITAL-HERMES est une solution globale personnalisée et optimisée pour le Luxembourg.
- Méthode de gestion des risques de sécurité OCTAVE® – For an organization that wants to understand its information security needs, OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability EvaluationSM) is a risk-based strategic assessment and planning technique for security.
- Différent outils méthodologiques élaborés et maintenus par l’ANSSI sur l’aide à la prise en compte de la sécurité dans les systèmes d’information. EBIOS – Expression des Besoins et Identification des Objectifs de Sécurité, PSSI – Guide d’élaboration de politiques de sécurité des systèmes d’information, TDBSSI – Guide d’élaboration de tableaux de bord de sécurité des systèmes d’information, GISSIP – Guide d’Intégration de la Sécurité des Systèmes d’Information dans les Projets, Guide relatif à la maturité SSI.
- La conduite de projet informatique vue par le CNRS. Le CNRS étant toujours une référence en France, je vous invite à découvrir la méthodologie en conduite de projet que le CNRS préconise pour le domaine des Systèmes d’Information.
- D’autres liens / other links : Papers, Links and Project Management Resources.
En « cascade » + RUP + Agile : Complémentarité plutôt qu’opposition
J’ai apprécié cet article où l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et plus récentes.
Le choix entre les méthodes « en cascade », RUP et agile, y dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dimension géographique.
Ce qui représente en soi, un bon exemple d’agilité dans le choix même de l’approche qui pourrait être une combinaison des trois méthodes selon les moments du cycle de développement.
Utilisez vous d’autres critères de choix de l’approche de développement?
En « cascade », RUP et Agile : quelle est la bonne méthode de développement logiciel pour vous?
Article original de Serhiy Kharytonov, SoftServe © 2009
Http://www.executivebrief.com/software-development/waterfall-rup-agile/
Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mélange des stratégies de développement de logiciels afin de répondre aux besoins spécifiques de votre projet.
Malgré les signes de reprise dans l’économie, la réalité persiste dans le développement logiciel. La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible. Pour atteindre ces buts apparemment contradictoires, les développeurs cherchent à rationaliser la production avec les processus rapides, efficaces qui peuvent donner au client ce qu’il/elle veut en un laps de temps le plus court possible.
Ces faits et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel du passé, souvent appelé le modèle « en cascade », aux modèles plus itératifs et progressifs tels que « Rational Unified Process (RUP) » et « Agile. »
Les partisans d’Agile sont nombreux et il peut parfois sembler que des processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, des côtés négatifs et leurs environnements de projet favoris. Au bout du compte, la meilleure méthode ou le meilleur mélange de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, la culture business et l’environnement de développement.
En « cascade »
La programmation en « cascade » est un processus fortement structuré qui compte lourdement sur la planification initiale et un ensemble d’étapes séquentielles, prescrites qui coulent de l’une dans l’autre comme une chute d’eau. Chaque étape a typiquement son équipe propre d’experts et des jalons soigneusement préparés d’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète avec des résultats qui sont fortement prévisibles.
Typiquement les étapes dans le développement en « cascade » sont :
- Recueil des besoins et rédaction du cahier des charges
- Analyse fonctionnelle
- Développement du code
- Intégration
- Test et mise au point
- Installation
- Maintenance
Le développement en « cascade » peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.
Les détracteurs disent que la « cascade » demande simplement trop longtemps et manque de la flexibilité – ou de l’agilité – requise pour le marché logiciel d’aujourd’hui et un environnement de développement en constant mouvement. Les projets qui suivent la méthode en « cascade » prennent typiquement des mois ou des années et au moment où ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut être des corrections onéreuses, explosant le budget.
RUP
Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin d’accommoder le changement et l’adaptabilité pendant le processus de développement.
Comme la « cascade », RUP a une série de phases et des jalons qui coulent l’un dans l’autre. Les phases consistent en :
- Création (« inception »), où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
- L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
- La construction, où le logiciel est construit et testé et la documentation de support est produite.
- La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.
RUP définit aussi les rôles et les activités de membres de l’équipe en détail et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que les grandes quantités de documentations requises pour chaque étape de la « cascade ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de directives, modèles, outils et autres articles pour assurer qu’ils partagent les mêmes langage et perspective sur le projet.
Alors que cela apparaît semblable au développement en « cascade » de prime abord, la plus grande différence du RUP est son approche de développement itérative, qui construit le produit dans plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin et d’architecture et l’exploration d’idées différentes, tandis que les itérations ultérieures essayent de rassembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.
Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours d’utilisateur.
RUP adresse bon nombre des critiques du développement en « cascade » et est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.
Les critiques disent que RUP n’est pourtant pas aussi rapide et adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial ou bien pour le Web 2.0 et les environnements Software-as-a-Service (SaaS) où on s’attend à des mises à jour fréquentes et des compléments de fonctionnalités.
Agile
Tandis que la « cascade » et RUP penchent vers la prévisibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, y compris XP et SCRUM, mais tous s’efforcent de mettre une version de produit basique mais fonctionnelle entre les mains du client aussi vite que possible.
Ils font alors suivre cette version par des versions successives qui ajoutent et changent des fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes sessions de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme la « cascade » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.
Plutôt que de dépendre de nombreuses équipes d’experts, le processus de développement Agile entier est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client, qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La collaboration en face à face constante est le but, avec le représentant du client utilisé comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à la « cascade » et même à RUP pour sortir quelque chose aussi rapidement que possible.
Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement de besoins et des défis compétitifs, qui sont les raisons de tant de partisans. British Telecom est fréquemment cité comme une société qui a utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont rapporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.
Mais même s’il est facile de tomber amoureux d’Agile, elle a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rendent le processus difficile à adapter à l’externalisation des développements, aux clients et développeurs géographiquement distribués, ou aux clients qui n’ont tout simplement pas la main d’œuvre, les ressources ou l’attention nécessaires.
Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas facilement aux clients qui veulent des contrats avec des évaluations fermes et des calendriers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec beaucoup de parties prenantes aux besoins différents et néglige de prendre en compte du besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.
De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec la « cascade » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.
Le meilleur de chaque monde
Si Agile, RUP et des modèles en « cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret au développement logiciel réussi est de comprendre les trois processus dans le détail et sélectionner les parties de chacun qui conviennent le mieux à votre livrable et environnement particuliers. Puis, être agile dans l’approche même du processus, en regardant sans cesse sur ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux à vos circonstances actuelles.
Par exemple, si vous développez du logiciel SaaS ou Web 2.0 dans un marché fortement concurrentiel, alors vous ferez probablement le meilleur choix en penchant vers des méthodologies Agiles. SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour ajouter ou changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateur changeants vous voudrez probablement être capables d’apporter rapidement des changements.
D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou d’autres systèmes qui exigent un haut degré de conception et de certitude, alors il semble logique de commencer par la « cascade ».
Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui doivent être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière au recueil des besoins, à la définition du périmètre et du contenu au début, ainsi que des standards de navigation, et d’interface utilisateur.
Cependant, les développeurs peuvent tout de même utiliser des techniques Agiles pour présenter des prototypes fréquents et des modules progressifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de société – selon que ces équipes soient plus ou moins habituées à une telle collaboration. Quand la géographie est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.
Ce même mélange de techniques peut être utilisé dans un environnement d’entreprise externalisant le développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contact de suivi qu’il est possible pour votre projet, la culture de votre société et celle de vos partenaires de développement.
Choisir de partir sur des équipes auto-organisées ou une approche plus « top-down » de management dépend vraiment du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leader qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins pour les itérations suivantes.
Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et environnements, ni même pour un seul. C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement. Bref, en choisissant entre Agile, RUP et en « cascade », adaptez le processus à vos besoins, plutôt que d’adapter votre projet au processus.
why quick fixes often lead to more trouble
As project managers, we’re often compelled to get roadblocks out of the way as fast as possible so the team can continue to progress. Therefore, we’re quite often in problem solving mode, trying to resolve issues that arise, avoiding and mitigating risks. A useful thing to keep in mind is to always consider whether we are really addressing the issue or only a symptom of the issue. Is our quick fix action aimed at the root cause of the issue or is it a step in the right direction as we fix the symptom? If yes, that’s ok and we shall apply the quick fix. But it’s not always the case…
This post is inspired by a training session I organized and attended for the management board of the PMI France-Sud non-profit organization a couple of years ago. Jerry Brightman, a renowned leadership expert and President of a company called The Leadership Group, was kind enough to facilitate this session.
Let’s take an example to illustrate the topic: a team member comes into your office to announce a probable delay on one of his deliverables. I propose that we walk through this case to better understand what could be happening.
The way it usually starts:
1. We see a problem, or to be more precise the symptom of a problem. I.e. by definition of a symptom: « a sign, indication, manifestation; something caused by and indicative of a certain disease or disorder. » In this example, a team member signals that he may not be delivering his part of the project on time.
2.We apply a quick fix. This deliverable is on our critical path, we propose to provide some additional assistance to the person to get the task completed on time.
Let’s assume that indeed this fixes the symptom. In our example, the task is back on track.
However, are we sure to have
a) addressed the root cause of the problem and
b) assessed the potential side effects of the quick fix we applied?
Let’s see what too often takes place after the initial quick fix.
3. The quick fix addresses the symptom but it has some side effects. For example, the additional help provided provokes a delay on another task from which we pulled some resources, or it generates requests from many others to get more resources, or it demotivates team members who were going the extra-mile to be on time, or…
4. These side effects will manifest through new symptoms: Bad morale in the team, threats of delays in other parts of the project, absenteeism…
5. We’re tempted to address these new symptoms with more quick fixes.
The loop goes on. The initial quick fix may have placed the entire project at risk.
So, what to do? How do we break the vicious spiral?
The proposal is to try by all means to avoid entering into this spiral.
In step 1, when we see the symptom (the threat of a late deliverable that is on the critical path), we take a step back to understand why the symptom is there and what caused it. We will want to ask a few questions such as:
- Were the estimates incorrect?
- Did a risk materialize that we had or not accounted for?
- Were there changes to the requirements and how were these managed?
- Were some resources not available when they should have been?
- Was the learning curve incorrectly appreciated?
- Did we encounter technical issues?
We see that the answers to the above questions may drive us in step 2 to a completely different quick fix that should be better suited to address the primary/root cause and avoid or anticipate some of the side effects.
As Seth Godkin highlighted it in of his posts: Bear shaving will not resolve global warning.
Or what my first aid teacher repeated to his students: « Do not put a Band-Aid on a non disinfected wound. »
DantotsuPM.com 