articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
In the third edition of PMI’s Standard for Program Management, the change management aspects are emphasized.Michel Thiry, MSc, FAPM discusses how Version 3 of PMI’s Standard for Program Management takes a more strategic view of program management and introduces important concepts such as adaptive change and transition.
« Je suis diplômée de l’Institut National des Télécommunications en 1994. Après une carrière à l’international dans l’IT, j’accompagne aujourd’hui les individuels et entreprises dans l’amélioration des compétences humaines via le coaching et la formation. Je suis également responsable de la section Leadership du MBA Telecom les Mines « Leading inovation in a digital world » et interviens en développement personnel & professionnel dans plusieurs autres organismes. » Sofia Rufin, Luxor Group Formations, Conseil & Coaching
• 75% de sociétés n’ont pas de processus pour anticiper et gérer les changements et futures tendances
• 83% des directions attendent des changements substantiels dans leur organisation sans pouvoir les prédire
• 50% des employés ne font pas confiance à leur management
L’agilité organisationnelle est la faculté de s’adapter continuellement à un environnement complexe. Elle permet de développer un panel de compétences permettant de réagir aux changements rapidement et
d’identifier de nouveaux angles de croissance.
Dans un environnement en constante évolution, renforcer l’agilité de l’entreprise permet d’anticiper et de répondre aux challenges et opportunités avec des managers flexibles, opportunistes et focalisés sur les objectifs.
Développer sa vision, sa compréhension des situations complexes, sa capacité d’analyse et d’organisation, se projeter pour voir le long terme et prendre de la hauteur
Influencer, amener de l’enthousiasme, aligner objectifs et méthodes, engager les acteurs internes et externes à l’entreprise dans une collaboration efficace, mettre le team building en avant…)
Mettre en exergue les options avec les challenges et obstacles rencontrés, gérer les problèmes d’ordres technique et humains, renforcer son esprit de décision, impliquer diverses ressources.
Trouver des perspectives inédites, ré-évaluer les actions passées en internes et pour les clients, définir les alternatives, sortir du cadre conventionnel, de ses limites, innover !
Se focaliser sur les objectifs finaux, développer son « accountability », poser les jalons adéquats et agir pro-activement, mettre en place un système de mesures rationnel et systémique (metrics) auquel se référer régulièrement et qui peut évoluer dans le temps…et communiquer l’avancement et le succès des projets en donnant du feed back.
Oui, un questionnaire est disponible, le LAP (Leadership Agility Profile) fondé sur l’Agile Model® (élu l’un des meilleurs modèles en leadership par l’AMA, American Management Association)
Le LAP permet de mesurer notamment ses ressources (ou celles de l’équipe) dans les 5 axes de l’agilité et de mettre en place son « development planner » et plan d’actions.
Télécharger le Livret Blanc/White paper (référence et accréditations): Leadership agility model
http://www.consult-llewellyn.com/8-accelerators-of-change Sur Consult Llewellyn
70 % des personnes qui sont assignées pour mener une initiative de changement tombent dans les pièges qui sont souvent décrits mais pas suffisamment évités pour permettre un changement vraiment efficace, réussi et soutenu.
John Kotter dit que (mis à part les startups) peu réussissent à utiliser le potentiel humain et à diriger l’énergie sur les challenges de grandes entreprises parce qu’ils travaillent dans un système qui demande essentiellement à la plupart des personnes de se taire, de prendre ses ordres et d’exécuter leurs emplois d’une façon répétitive.
John Kotter a publié un nouveau rapport qui aide à renverser la tendance en “accélérant le changement”.
1. Créer le sens de l’urgence autour d’une unique grande opportunité. Ceci est absolument critique.
2. Construire et entretenir une coalition directrice.
3. Formuler une vision stratégique et développer des initiatives de changement conçues pour exploiter la grande opportunité.
4. Communiquer la vision et la stratégie et la vendre et attirer une armée de plus en plus nombreuse de volontaires.
5. Accélérer le mouvement vers la vision et l’opportunité en assurant que le réseau supprime les barrières.
6. Célébrer les victoires rapides qui sont visibles et significatives.
7. Ne laissez jamais tomber. Continuez à apprendre de l’expérience. Ne déclarez pas victoire trop tôt.
8. Institutionnaliser les changements stratégiques dans la culture.
Essentiellement ces 8 étapes créent d’abord un climat pour le changement, ensuite elles engagent et préparent l’organisation entière avant l’implémentation et le support du changement.
John Kotter explique que la première étape, la plus importante et la plus difficile dans le processus est d’établir notre sens d’urgence et de le maintenir tout le temps et partout dans notre processus de changement. La plupart des organisations aiment sauter cette étape, avec beaucoup de leaders de changement qui assument par erreur « puisque je ressent l’urgence, tous les autres doivent aussi la ressentir”. Ils mettent si peu d’effort à établir l’urgence que leurs efforts de changement échouent.
John Kotter a écrit “A Sense of Urgency” pour souligner l’importance de l’urgence et démontrer comment la créer et savoir quand vous l’avez. Dans ce livre, il a introduit le principe important “de la vraie urgence.” Il a écrit …
Elle est enracinée dans le leadership dans toute notre organisation. Quand nous l’avons réalisé avec succès, la chose suivante se produira :
En comprenant comment créer la vraie urgence parmi un nombre suffisant de personnes qui sont concentrées sur une forte valeur et un travail avec beaucoup d’impact est crucial à la réussite du changement.
Hors sujet par rapport à la gestion du changement dans les organisations notamment grâce aux projets, mais néanmoins utile je pense aux chefs de projets, ce rappel des principes de base du contrôle des modifications au sein du projet avec cette vidéo en anglais de Jennifer Whitt: « What Is Change Management? »
Projects and programs by their nature create change, and sophisticated organizations know strategic change happens through projects and programs. Project, program and portfolio managers who want their organizations be successful need the skills to manage change front and center in their talent portfolio.
To answer this growing need, PMI has launched Managing Change in Organizations: A Practice Guide – currently available for free download for a limited time only. This guide helps project and program managers successfully identify change elements and account for them within a project/program plan. It also helps create clear and powerful strategies to guide organizational development, including a means of executing those strategies reliably and effectively.
Not a separate role or function, change management is a skillset for project practitioners that bridges leadership, business acumen and technical skills. The guide is the culmination of PMI’s 20 years of thought leadership in change management and is the definitive guide to help you lead a proactive, planned approach to change.
Take an in-depth look at change management practices embedded in PMI’s foundational standards. It is a practical resource for effective change management in projects and programs.
For a limited time, download a free PDF of the Guide (a US$34.95 value).
http://www.projectinsight.net/community/blogs/online-project-management/archive/2012/04/17/what-if-your-customer-isn-t-interested.aspx par Brad Egeland
Wow… avez-vous jamais eu un de ces projets où vous regrettez que le client ne soit pas invisible ? Où vous auriez souhaité qu’ils se poussent de côté et vous laissent, vous et votre équipe, manager le projet et implémenter la solution. Aucun besoin vague, aucune question ni constante surveillance… …juste naviguer par mer calme jusqu’au déploiement final. Cela pourrait être glorieux.
Ce serait plus probablement désastreux n’est-ce pas ? Pensez-y … Oui, il serait agréable de pas avoir le client qui se mêle sans cesse de votre travail. Ce serait agréable s’ils arrêteraient de demander des changements ou de triturer les besoins, vous pourriez progresser plus librement. Mais sans ces interactions du client sur le projet, vous ne connaîtriez pas les changements nécessaires et finiriez par livrer une solution finale qui rate la cible.
Voici la préoccupation: vous devez toujours respecter les attentes de votre client pour parvenir à une mise en œuvre réussie. Vous devez toujours satisfaire les besoins. Vous devez toujours livrer aux utilisateurs finaux du client un produit qu’ils peuvent utiliser. Même si le client choisit de ne pas participer, pour ne pas faire partie de l’équipe et avoir à commenter tout ce qui est fait, si vous livrez une solution finale inutilisable, alors vous échouez quand même. Aïe.
Si vous êtes le chef de projet et que vous vous trouvez dans une situation où le client ne participe pas, ne prend pas de rôle actif ou ne montre pas un intérêt dans le projet…soyez inquiet…soyez très inquiet. Si ceci commence vraiment à être le cas pour vous sur votre projet, il y a quelques choses vous allez devoir faire pour vous couvrir, vous, votre équipe et votre organisation comme vous avancez sur le projet. Examinons les parce qu’elles sont probablement votre meilleur espoir de sauver le projet ou au moins votre peau si les choses tournent mal.
Si vous et votre équipe avez besoin de choses du client que vous n’obtenez pas juste parce qu’ils ne participent pas, vous vous trouvez devant le besoin d’aller de plus en plus haut et cela peut vous amener à contacter le PDG de l’organisation client. S’ils dépensent toujours de l’argent sur le projet, mais ne participent plus, il est probable que leur PDG ne sait pas qu’il met de l’argent dans un projet qui peut être sorti de piste en raison du non-respect des engagements côté client. Attirez l’attention de leur management senior, priez-les de participer à la prochaine réunion d’avancement. Faites du remue ménage pour pouvoir commencer à obtenir un peu de participation du client. Si vous ne criez pas assez fort, le blâme pourrait bien retomber sur vous.
Si votre client ne participe pas, vous avez besoin de le documenter . Et encore mieux, vous devez continuer à tout documenter. Sauvez chaque itération de chaque échéancier que produit votre logiciel de planification de projet. Documentez tout qui se produit en chemin. Chaque réunion manquée par le client, chaque supposition que vous avez dû faire sans apport du client, chaque endroit où vous avez eu besoin de l’interaction client, mais ne l’avez pas obtenu et chaque fois vous avez livré et reçu aucun retour…documentez cela.
Peu importe combien ils sont peu coopératifs ou non-participatifs, n’arrêtez jamais de leur fournir vos rapports de statut hebdomadaires, les échéanciers révisés de projet de votre logiciel de conduite de projet et les informations budgétaires sur le projet. Continuez à leur donner tout qui a été agréé au moment du démarrage. Et continuez à tenir des réunions de statut hebdomadaires même si elles ont seulement suivies par vous et votre équipe projet !
Quand tout le reste échoue et que vous sentez que le projet souffre trop parce que le client ne participe pas, arrêtez le travail. Documentez l’interruption dans votre échéancier. Cela peut les faire sortir du bois. Au minimum, cela vous empêchera de continuer sur une mauvaise voie à faire des suppositions avec lesquelles vous n’êtes pas à l’aise et à prendre des décisions que vous ne pouvez pas confirmer avec le client.
Il est peu probable qu’un projet qui parte dans cette direction finisse avec succès. Il y a trop en jeu et trop de chances que le projet finisse mal si le client ne participe pas du tout… …et vous êtes celui qui pourrait en recevoir tout le blâme. Faites ce que vous pouvez pour les faire s’impliquer. Si cela ne marche pas, documentez tout ce que vous pouvez. Et si cela ne fonctionne toujours pas et que les choses vont mal, arrêtez de travailler sur le projet. Documentez-le et communiquez-le pour vous protéger, vous, votre équipe et votre organisation.
Et oui, le mercredi 20 mars marque le début du printemps.
http://www.ginaabudi.com/spring-is-coming-lets-do-some-process-clean-up Par Gina Abudi
Tout business devrait régulièrement passer en revue ses processus. Un peu comme nous avons tendance à nous lancer dans le grand nettoyage de printemps à la maison quand cette saison arrive, pourquoi ne pas en profiter cette année pour passer en revue vos processus business ?
Je conseille à mes clients de régulièrement revisiter leurs processus, idéalement deux fois par an, mais au minimum annuellement. Quand les processus sont régulièrement revus et peaufinés, ils augmentent en efficience et en efficacité [ndlt : L’efficience est l’efficacité au moindre coût].
Vous pourriez vouloir réaliser ceci par une combinaison d’enquêtes, de réunions de services, en petits groupes et individuelles. Ce simple processus de revue, réalisé à intervalles réguliers, vous permet de trouver des façons d’améliorer comment le travail est fait.
Quand vous trouvez des opportunités d’améliorations, assignez une équipe d’amélioration de processus à cette initiative. Assurez-vous que l’équipe comprend une bonne représentation des diverses fonctions.
http://www.projecttimes.com/articles/the-kaizen-project-manager.html Par Jarett Hailes
Les chefs de projet ont la tâche difficile d’assembler une équipe pour produire quelque chose d’exceptionnel, souvent dans des contraintes de budget et d’échéances serrés. Dans ces situations sous pression, les équipes projet doivent pouvoir fonctionner ensemble d’une façon aussi optimale que possible. Même si les équipes nouvellement formées ont souvent besoin de temps pour trouver leur rythme et développer des processus efficaces, une équipe expérimentée avec plusieurs projets derrière elle peut aussi constater que les façons de faire son travail pourraient être réalisées plus efficacement.
Une approche est d’essayer de découvrir des inefficacités majeures et d’implémenter de grands changements de fond en comble. Ces types de changements sont souvent les plus difficiles à réaliser, indépendamment de si votre équipe projet comporte deux personnes ou mille. De grands changements sont envisagés avec la crainte, le doute, l’inertie, la paresse et bien d’autres barrières. Notre enthousiasme initial pour le changement peut diminuer s’il n’y a pas de résultats immédiats et à la fin il peut y avoir une décision consciente ou inconsciente d’abandonner le changement. C’est pourquoi tant d’entre nous laissent tomber les résolutions du nouvel an; souvent ce sont de grandes déclarations visionnaires qui impliquent une grande quantité de changement.
Au lieu d’essayer de faire de grands changements, nous pouvons nous concentrer sur l’implémentation d’un processus de développement progressif qui permet aux équipes projet de continuellement s’améliorer avec des changements petits mais significatifs. Le terme japonais « kaizen” signifie “amélioration continue” et des méthodologies ont été développées qui implémentent kaizen par petites étapes, progressives et constantes pour apporter des changements spectaculaires après quelques temps. Kaizen a été utilisé dans des méthodes industrielles « Lean » dans des sociétés comme Toyota, Intel et Lockheed Martin. Bien que cette méthodologie a été utilisée principalement dans des environnements industriels, elle se concentre sur aider les personnes et petites équipes à devenir aussi efficaces et efficaces que possible dans le travail qu’elles font.
Pensez à des façons de faire que quelque chose se produise plutôt que des raisons pour lesquelles quelque chose ne peut pas être réalisée.1. Développez l’attitude mentale
Quand vous arrivez au travail, prenez 30 secondes pour vous rappeler qu’aujourd’hui vous avez l’opportunité de trouver des façons de mieux faire votre travail. Revoyez ce que vous ferez aujourd’hui et votre plan pour réaliser ces choses. Quand vous rassemblez votre équipe projet pour des réunions d’avancement, débutez la rencontre avec une déclaration similaire qui renforce cette mentalité chez chacun dans le projet.
2. Documentez la performance
Les équipes projet suivent souvent leur temps passé sur des activités et utilisent des méthodes comme la valeur acquise pour déterminer si le projet progresse bien. Regardez s’il y a d’autres mesures de performance qui sont appropriées à votre équipe projet. Par exemple, si vous travaillez sur un projet logiciel, peut-être le nombre de passage en revue d’un document de besoins utilisateurs peut être utilisé pour évaluer la performance d’un analyste business. Dans le bâtiment et les travaux publics, le nombre d’incidents liés à sécurité peut être une mesure importante. Travaillez avec votre équipe pour trouver des manières significatives de démontrer la progression et utiliser les périodiquement pour évaluer comment votre équipe avance.
3. Réfléchissez sur vos activités
A la fin de la journée, passez rapidement en revue le travail que vous et votre équipe avez exécuté. Réfléchissez à ce qui est bien allé et ce qui ne s’est pas déroulé idéalement. Prenez quelques notes rapides et associez-les aux tâches appropriées auxquelles elles appartiennent. Pour les secteurs qui ne sont pas allés aussi bien que souhaité, noter 1 ou 2 choses qui pourraient avoir été faites différemment et auraient amélioré le résultat. Réunissez votre équipe chaque un ou deux jours pour passer en revue ce qui selon les personnes va bien et ce qui peut être amélioré. Convenez d’au moins un item qui peut être implémenté immédiatement, peu importe sa taille. S’il y a de plus grandes choses qui exigeront quelque temps pour être implémentées, faites un brainstorming sur comment vous pouvez intégrer ces activités dans vos plans et tirer les bénéfices de cette amélioration.
4. Faites des essais avec de nouvelles idées
Trouvez des choses intéressantes qui selon vous aideront à améliorer la qualité ou l’efficacité du travail de votre équipe et essayez-les. Partagez ces idées pendant votre évaluation périodique de performance de l’équipe. Selon la taille de l’équipe, cela peut avoir du sens de développer une méthode de priorisation pour choisir quel item implémenter, car vous ne pourrez probablement pas tout essayer. Une fois que l’idée est en place, suivez les métriques de performance dont vous aviez pensé qu’elles changeraient et comparez-les aux résultats précédents. Une évaluation qualitative peut aussi être justifiée (par exemple, si chacun dans l’équipe est plus heureux avec son travail grâce au changement). Après avoir tester l’idée pendant une période raisonnable pour juger si elle est utile, laissez l’équipe décider s’il faut continuer ou l’éliminer.
5. Partagez avec d’autres
En dehors d’avoir votre équipe qui collabore sur des idées kaizen, vous pouvez regarder d’autres projets dans l’organisation pour des leçons apprises et différentes façons de faire des choses. Discuter avec d’autres chefs de projet à travers votre chapitre PMI local est aussi une façon de trouver des idées qui peuvent aider vos équipes projet à réussir encore plus. S’il n’y a aucun chapitre dans votre région, des communautés en ligne de chefs de projet avec des forums virtuels vous offrent une excellente chance de collaborer avec des pairs dans le monde entier.
Comme noté ci-dessus, cette approche marche idéalement dans de relativement petites équipes pour que tous les individus sentent qu’ils sont une partie intégrante du processus. Si vous avez une plus grande équipe projet, vous pouvez diviser l’équipe en sous-groupes pour pratiquer le kaizen. Des groupes kaizen transverses peuvent souvent découvrir des inefficacités aux frontières organisationnelles qui vont autrement passer inaperçues, donc si possible, combinez dans vos équipes des jeux de compétence et des expériences divers. Si vous avez de multiples sous-groupes, donnez aux représentants de ces sous-groupes une chance de se réunir de temps en temps pour partager les idées qui ont prouvé faire augmenter la productivité.
Ces étapes peuvent être aussi exécutées pour vous aider à améliorer vos propres processus de chef de projet. Une approche kaizen à l’amélioration personnelle peut éliminer la crainte et le risque de grands changements dans vos pratiques en vous donnant une chance de régulièrement passer vos actions en revue et de réfléchir aux façons d’accroître votre efficacité de leader. Quand cela est combiné avec l’exécution kaizen au niveau d’équipe, vous avez mis en place une excellente approche pour adresser rapidement n’importe quels problèmes auxquels votre projet peut faire face.
Avoir de grands objectifs peut être un incroyable élément de motivation pour aider des équipes à atteindre le succès. Parfois il peut être si facile de visualiser ce que nous voulons accomplir que nous essayons de faire d’énormes changements pour atteindre notre but aussi rapidement que possible. Cependant, comme un vieux proverbe chinois nous le rappelle, “Il vaut mieux faire beaucoup de petites étapes dans la bonne direction que de faire un grand bond en avant seulement pour trébucher en arrière.” Avoir une approche de kaizen à l’amélioration de vos projets et de vos compétences de chef de projet fournit une opportunité de faire des changements petits mais constants chaque jour qui sauront provoquer des résultats incroyables.
Socializing Your Project Initiatives
http://www.ginaabudi.com/socializing-your-project-initiatives par Gina Abudi
Trop souvent les chefs de projet ne prennent pas en considération l’importance de socialiser leurs projets avant de commencer le travail sur le projet. C’est peut être parce qu’ils n’ont pas pensé aux avantages de le faire ou parce qu’ils estiment que le projet est déjà agréé et décidé, donc pourquoi se donner cette peine. Cependant, les chefs de projet les plus efficaces, ceux qui adoptent une approche stratégique dans comment ils mènent leurs projets, regardent les projets tant de la perspective de l’organisation que de la perspective de l’individu. Ils comprennent ainsi les avantages à socialiser le projet dès le début , pendant les étapes de pré-planification.
Sans aucun doute, vous aurez à mettre en évidence les bénéfices de socialiser les projets auprès de votre sponsor et autres parties prenantes de projet si ce n’est pas déjà une pratique courante dans l’organisation. Prenons un exemple. J’ai été appelé pour travailler avec un client qui, environ 5 mois auparavant, avait lancé un projet de changement des processus de capture et de saisie des données clients pour permettre d’améliorer le marketing. Ils n’ont pas commencé par socialiser le projet. Les utilisateurs finaux faisaient ce travail d’une façon particulière depuis environ 4 ans. L’habitude est une seconde nature. Personne ne voulait changer ce qu’ils faisaient car cela fonctionnait pour eux. Nous en étions déjà à 5 mois dans le projet quand j’ai été appelée pour aider à rectifier la situation car le progrès était très minimal. J’ai recommandé qu’ils prennent du recul et reparte de zéro en prenant cette fois du temps pour socialiser l’initiative et discuter des avantages pour l’organisation dans son ensemble, les services spécifiquement affectés et les personnes. D’abord, cependant, nous avons eu besoin de faire un peu « de travail de réparation » pour lisser les ressentiments.
Quand nous prenons le temps de socialiser les projets avant que nous ne les commencions en réalité, nous fournissons aux personnes un signal sur ce qui se passe et pourquoi. De cette façon, nous donnons un sentiment de confort par rapport aux changements qui surviendront. Cela nous aide à :
mieux gérer les attentes dans tout le projetJe considère que socialiser le projet fait partie de la phase de définition ou de pré-planification du projet. Cela m’aide à découvrir qui supporte le projet et avec qui je devrai passer un peu plus de temps pour les rendre confortables et les convertir en champions. Selon la taille et la complexité du projet et le nombre de personnes dans l’organisation, je peux planifier de deux semaines à quelques mois de socialisation de l’initiative.
Si vous êtes dans une organisation qui n’a jamais socialisé de projets avant leur lancement, vous pouvez devoir vendre l’idée aux cadres exécutifs. Ce n’est pas aussi difficile que vous pourriez le penser. Tout d’abord, dans la plupart des cas, en tant que chef de projet, vous connaissez les projets à venir avant qu’ils ne soient réellement prêts à commencer. Commencez dès lors à socialiser le projet! Quand je travaille avec des clients pour les aider à développer des manières plus efficaces et effectives de manager leurs projets, je m’assure que les plans incluent l’implication des chefs de projet très en amont dans les décisions initiales des projets pour que, avant le lancement réel, du temps puisse être mis de côté pour socialiser l’initiative. Rarement prenons-nous sur le temps de projet. Et, quand nous prenons vraiment sur le temps de projet, nous avons prouvé, maintes fois, qu’en socialisant en amont, nous passons en réalité moins de temps au final à gérer les attentes et nous obtenons beaucoup plus d’engagement qui permet un management améliore du projet au cours de son exécution. De plus, nous avons trouvé dans quelques situations, qu’en socialisant le projet, nous avons appris plusieurs choses que nous n’aurions pas su et qui aurait plus tard fait dérailler le projet.
Fréquemment nous regardons les projets de la perspective de l’organisation. Nous comprenons comment le projet bénéficiera à l’organisation et pourquoi c’est la bonne chose à faire. Nous avons tendance à oublier l’individu. L’individu est celui qui sera impacté par le projet d’une certaine façon. Nous devons considérer le projet depuis la perspective de l’individu, qui, bien que certainement concerné par l’organisation est aussi concerné par lui-même. C’est simplement naturel. Les questions qui traversent l’esprit de cette personne sont par exemple « qu’arrivera-t-il à mon travail ? » « Pourrai-je continuer à remplir mon rôle si il change ? » « Et si je n’avais pas les compétences dont j’ai besoin ? » « Comment puis-je traiter tout cela quand j’ai tant de choses à faire ? ». Ce sont toutes des préoccupations valables de la part de collaborateurs individuels et les projets les plus réussis sont exécutés par ceux qui travaillent avec cette personne pour adresser ses préoccupations de différentes façons, comme :
Voici seulement quelques moyens de socialiser le projet partout dans l’organisation. Choisissez toujours différentes solutions afin d’atteindre le plus grand nombre de personnes.
Prenez le temps de socialiser vos projets avant leur réel début. Vous constaterez que vous augmenterez l’engagement et le support au projet, ce qui rendra votre travail de management du projet beaucoup plus facile à long terme. Les bénéfices sont multiples et bien supérieurs à l’effort supplémentaire demandé. Souvenez-vous aussi, que, périodiquement, pendant tout le projet, comme toute bonne pratique, vous devez continuer à socialiser le projet en faisant le point avec les personnes pour être certain qu’ils sont toujours bien engagés et confortables avec ce qui se passe.
Voici quelques billets postés sur DantotsuPM sur ce sujet qui est souvent au cœur des problématiques de dérives de coûts et de délais : la Gestion des changements
http://blog.prince2.com/2012/07/getting-to-grips-with-prince2-themes sur PRINCE2.com Blog
Tout un chacun peut avoir une idée brillante pour un produit ou un service. Le truc est de vous assurer que vous suivez les bonnes étapes pour transformer l’idée en réalité. Les thèmes PRINCE2 vous aident à le faire. Ils représentent les sept aspects critiques de management de projet qui, pris en compte et considérés partout dans le projet, en feront un succès.
Vous avez une grande idée, mais comment savez-vous qu’elle paiera ? Le cas d’affaires, le « business case », vous permet d’équilibrer les bénéfices attendus avec les risques et les coûts estimés. Tant que les bénéfices dépassent coûts et risques, vous continuez avec le projet. Quand ils ne le font pas, vous arrêtez le projet. Voici un exemple simplifié : imaginez que vous avez décidé de réaliser X dans un an parce qu’il aboutira à Y. Vous avez regardé les risques et les coûts et ils semblent acceptables. Imaginez maintenant que vous êtes cinq ans et des milliers de dollars ou d’euros plus tard et, bien que vous n’ayez pas toujours X opérationnel, le projet avance en trébuchant. Et bien, si vous aviez seulement soumis votre idée à la rigueur du cas d’affaires PRINCE2, cela aurait réduit les chances de cette tournure d’événements.
Avez-vous jamais organisé un événement où chacun pensait que quelqu’un d’autre était responsable et que quelqu’un d’autre faisait ce qui être fait pour qu’à la fin rien n’ait été fait ? Si seulement chacun avait su comment utiliser PRINCE2. En termes très simples, le thème Organisation permet de s’assurer que les gens connaissent leurs rôles (rôles pas job, parce que les rôles peuvent être partagés et combinés) et savent à qui il reporte. En fait, il s’assure que certaines personnes dirigent, certaines managent et certaines livreront un projet. Résultat? Absolument!
Nous avons tous acheté quelque chose avec des caractéristiques et des résultats spécifiques promis et ensuite quand nous contemplons ce que nous avons reçu, ce n’est pas en accord avec nos attentes. PRINCE2 peut s’assurer que votre client ne subit pas de telles déceptions. La qualité est un thème clé de PRINCE2 qui peut s’appliquer à un produit, une personne, un processus, un service et/ou un système. En utilisant la méthodologie, vous pouvez être clairs sur ce que le client veut, que ce que vous et le client avez accepté sera acceptable, sur comment atteindre le résultat requis, sur ce que devrait être dans la description de produit et, vous pouvez aussi créer un registre de qualité qui récapitule les activités de qualité planifiées et complétées.
Nous utilisons tous des plans chaque jour, qu ce soit pour planifier notre journée, planifier comment faire quelque chose ou planifier comment aller quelque part. Le business n’est pas différent. La beauté de PRINCE2 consiste en ce que son thème Plans rend la planification d’un projet effective et efficace. Simplement dit, son approche de planification à base de produit/livrable dit à chacun qui est impliqué ce qui est exigé, comment cela sera réalisé, qui le réalisera, ce qu’ils utiliseront, quand les choses arriveront et si vous pouvez produire le livrable selon les paramètres impartis.
Si nous planifions un barbecue en été il y a un risque qu’il pleuve et d’arrêter l’événement; si nous construisons quelque chose qu’il y a un risque que notre fournisseur d’un composant ne livre pas à l’heure. Le risque est tout autour de nous et cela peut être positif et négatif. Le but avec le thème Risque de PRINCE2, est de le manager selon des étapes comme avoir une stratégie, un registre de menaces et d’opportunités et une procédure de management des risques.
Vous avez créé un produit et avez tout bien fait et ensuite, le croirez-vous, quelqu’un décide qu’il veut changer l’emballage. Eh bien, peut-être le croiriez-vous. Les projets, comme la vie, sont sujets au changement. Tout que vous pouvez faire est manager le changement. L’utilisation d’une approche systématique et commune du thème de Changement de PRINCE2 permet d’identifier, localiser et contrôler des changements inattendus ou attendus par rapport aux lignes des références établies pour les livrables. (Vous avez besoin de lignes de référence, sinon vous ne saurez pas quel est le changement.)
Ceci est en quelque sorte une évidence. Après tout, à quoi bon nous féliciter de nos accomplissements si ceux-ci ne répondent pas aux besoins du projet. Ainsi, le thème de Progrès PRINCE2 vous aide à garder un œil vigilant sur comment les choses avancent. Il implique le contrôle et la comparaison du réalisé avec les résultats planifiés, fournissant une prévision des objectifs et de la viabilité du projet et implique le contrôle de tout écart inacceptable. Les sortes de choses que l’on regarde sont les coûts , les délais et la qualité et celles-ci permettent alors des décisions informées comme s’il faut arrêter un projet en cours.
Kiron D. Bondale, PMP est le Directeur du PMO de Agricorp. Kiron a travaillé pendant plus de treize ans dans le domaine du management de projet avec un focus sur la gestion des changements et la technologie. Il a mis en place et managé des PMOs et a fourni des services de conseil de PPM à des clients de diverses industries. Kiron a servi en tant que directeur du Chapitre PMI de Lakeshore pendant six ans et reste un membre actif de PMI. Il a publié des articles sur le PPM et le management de projet dans des journaux de multiples industries et a donné des présentations sur le domaine de PPM/PM dans de nombreuses conférences et webinars. Pour en savoir davantage sur Kiron, visitez son blog http://kbondale.wordpress.com
Félicitations !!! Vous avez convaincu que votre direction qu’implémenter une approche cohérente de management de projet est une étape clé pour atteindre la vision stratégique de votre société !
Une fois que votre euphorie initiale s’évapore, vous en viendrez à vous rendre compte que vous avez seulement gagné la première bataille d’une longue campagne. Maintenant vous devez gagner les cœurs et les esprits des chefs de projet. Cela peut être un vrai défi quand les chefs de projet expérimenteront probablement de très grands changements dans leur routine habituelle.
Cette préoccupation semble contraire à l’intuition : les chefs de projet devraient être les adversaires de l’entropie et sûrement il n’y a meilleure méthode pour mettre de l’ordre au chaos organisationnel qu’en instituant des pratiques cohérentes ?
Cette supposition ignore quelques vérités de base:
Un changement de processus (quels qu’en soient les avantages) réduit d’habitude la productivité pendant une courte période de temps jusqu’à ce que le changement soit entièrement assimilé. Sauf dans de rares exceptions où l’avantage du changement compense immédiatement l’effort perdu dans l’étude et l’adoption des nouvelles pratiques.
Comme avec la plupart des défis de management du changement « en douceur », il n’y a aucune baguette magique, mais une combinaison des techniques suivantes devrait aider:
1. Faites-les participer – personne ne veut adopter un changement dans lequel ils n’ont eu aucun apport. Identifiez chefs de projet les plus vocaux ou influents et impliquez-les dans la définition des nouvelles pratiques.
2. Prenez une approche « Lean » – Changer pour l’amour du changement va seulement augmenter la probabilité de résistance, alors assurez-vous que quelqu’un sur votre équipe pose la question « Pourquoi devons-nous faire ce changement spécifique » ?
3. Servez-vous du Code éthique – les Membres de PMI doivent adhérer à la Déontologie « Code of Ethics ». L’extrait suivant d’un des standards de bonne conduite est bien en ligne avec les avantages de pratiques cohérentes : « Nous acceptons la responsabilité pour tout problème résultant de nos erreurs ou omissions et toutes les conséquences résultantes.« . Un manque de pratique cohérente augmente le potentiel de problème sur les projets si une transition entre chefs de projet se produit.
4. Évaluez – que vous ayez ou pas la responsabilité formelle sur les chefs de projet, essayez de placer la conformité aux changements procéduraux dans leurs objectifs d’évaluation et incitez-les à être les champions de ces changements par une reconnaissance visible.
5. Déportez une partie de la charge de travail – pour les chefs de projet travaillant sur les projets les plus difficiles ou les plus gros, identifiez le personnel (ou les stagiaires) qui aspirent au métier de manager de projet et essayez de les recruter pour assister ces chefs de projet en tant que coordinateurs de projet. Les chefs de projet apprécieront probablement la capacité de se décharger des activités d’administration de projet sur des coordinateurs de projet et vous en bénéficierez en ayant « la prochaine génération » de chefs de projet déjà alignés sur vos nouvelles normes organisationnelles.
Je vous propose de lire le rapport « Distributed Agile Teams : Achieving the benefits » de Projects at Work.
On y trouve entre autre la table ci-dessous, ainsi que :
http://www.brighthub.com/office/project-management/articles/125813.aspx écrit par Michael Kirkham-Jones et édité par Michele McDonough
Comment rédigez-vous un contrat au forfait sur une proposition Agile embryonnaire ? Ce n’est pas aussi difficile que certains le font paraître mais cela implique un vrai changement de mentalité et un exercice d’apprentissage pour tout un chacun. Clairement définir « fait » (« done »), évaluer des histoires et comprendre la vélocité sont clés à la réussite.
Si toute l’idée d’Agile est que vous ne pouvez pas prévoir l’avenir, alors comment pouvez-vous l’utiliser dans un Environnement de contrat de forfait où il est essentiel de préciser vos coûts, votre temps et votre contenu de projet ? Peut-être que la réponse est de regarder au-delà de relier Agile à des modèles de contrat mal adaptés et de proposer une nouvelle structure.
OK, donc la chose fondamentale que nous pouvons affirmer de tout ce que nous lisons sur Agile est le fait que les besoins ont vraiment tendance à être très brumeux. Au contraire, le modèle de contrat fixe exige d’un jeu détaillé, stable et précis de besoins, définissant clairement des limites et des pénalités si quelqu’un pose le pied à l’extérieur de celles-ci.
Comment diable deux animaux si différents peuvent-ils coexister dans le même environnement ? Il y a tant de débat sur comment ceci peut être fait que couvrir chaque idée, pensée ou sentiment nécessiterait des dizaines d’articles. Je pense que ma meilleure approche est de décrire mon expérience et comment je configure un Contrat Agile.
Au tout début d’aborder la question d’Agile et forfait, il était impératif de partir d’une structure logique et professionnelle pour le processus. Je voyais si souvent des présentations où la société a offert une approche de toute évidence biaisée et il n’y avait absolument aucune chance que le projet puisse commencer, encore moins être complété. Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. Un travail bâclé se sent à un kilomètre.
Alors, comment approchons-nous une proposition de contrat au forfait ? La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts. Sur chacun de ces domaines, nous avons alors passé beaucoup de temps à définir et documenter clairement et précisément le quoi et le comment. Pour nous, cela nous a ouvert une structure complètement différente de notre organisation et a potentiellement ajouté de nouvelles sources de revenu.
Le temps et les coûts dans un contrat au forfait sont raisonnablement faciles à définir et pour Agile l’approche itérative a durée contrainte est très facile à définir. Ceci nous laisse donc seulement avec le problème du contenu/portée/périmètre. Comment pourrions-nous fixer les livrables sans étrangler la méthodologie Agile que nous suivons si fièrement ? Le problème était de changer le concept de contenu en un budget.
La toute première étape était de collecter les besoins des utilisateurs sous forme d’un arriéré de produit en utilisant des histoires utilisateur pour détailler les attentes des clients. Nous utilisons alors cet arriéré de produit pour prioriser puis évaluer les fonctionnalités en utilisant des techniques d’estimation de groupe comme le « Planning Poker » et donner des valeurs sous forme de points d’histoire « Story Points ».
En allant plus loin dans ce processus nous passons 1 à 2 jours à définir :
« L’histoire utilisateur est une façon d’exprimer des besoins qui sont compréhensibles pour les deux clients et nous-mêmes. Les histoires utilisateur sont rapides à écrire et impliqueront tous les niveaux de la structure d’organisation concernée. Elles sont, plus important encore, orientées fonctionnalité, donc elles peuvent fournir une bonne vue du contenu réel d’un projet et nous pouvons les comparer l’une à l’autre en termes de taille, d’effort « , etc [1]
Pour l’estimation, nous avons tendance à utiliser des points d’histoire par opposition aux jours idéaux ( Je discute de ceux-ci dans mon article sur les Burndown Charts). Il est très important de vous assurer que vous avez une vue très claire de « fait » (« done ») et que vous avez une définition explicite et concrète qui forme le point de contrôle critique du projet agile. Sans une compréhension cohérente de « fait » il sera impossible d’évaluer précisément la vélocité. « C’est aussi une façon de construire la confiance avec le client en ayant un consensus commun quant au processus de projet et sur le critère d’acceptation de haut niveau. « [1]
Ici, nous pouvons maintenant inventer une valeur définissant notre budget de contenu avec des points d’histoire. C’est cette valeur qui est fixée dans le contrat et non Pas les histoires.
Avec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?
La vélocité de l’équipe est basée sur beaucoup de facteurs, pas seulement combien de travail qu’ils peuvent réaliser. Nos pratiques de travail définissent déjà notre stratégie de communication et nous savons donc combien de temps est passé en réunions planifiées avec l’équipe et le client. Il y a d’autres facteurs à considérer comme les vacances, le volume des tâches, etc. En bout de ligne la vélocité journalière sera un nombre qui est en partie basé sur l’expérience, mais contient pas mal de suppositions (par exemple : si nous sommes en l’hiver, nous pouvons être sûrs que quelqu’un aura la grippe).
Disons par exemple que nous avons calculé que l’équipe peut livrer 30 points d’histoire par itération de 2 semaines et a 240 points d’histoire à livrer (tel que défini dans le contrat). Nous avons maintenant une durée de livraison de 8 itérations nécessitant 16 semaines en tout. Avec 70 heures allouées à chaque itération, une équipe de 5 personnes et un taux horaire de 100 € par membre de l’équipe nous pouvons facilement calculer le prix à 280,000 €.
Donc, maintenant nous avons nos valeurs de contrat fixes :
Ces valeurs font tout simplement partie de la procédure tarifaire du contrat et ils ont vraiment tendance à être les chiffres les plus difficiles à atteindre avec un niveau de confiance acceptable.
Ce que nous essayions de montrer ici est que la façon dont nous travaillons sur les projets Agile peut aussi se refléter dans l’environnement des négociations de contrat.
… Le propriétaire de produit « product owner » (le client) veut ajouter une autre fonctionnalité ? Nous avons déjà travaillé étroitement avec le client, à définir l’arriéré de produit, évaluer les points d’histoire, donc il connaît la situation actuelle. En cas de demande de travail supplémentaire nous évaluons l’ajout, disons 10 points d’histoire dans ce cas et nous négocions pour soit supprimer 10 points de valeur d’histoire de fonctionnalités agréée soit ajouter une itération de plus. Maintenant que nous avons fixé les points pour le contenu nous pouvons permettre à des changements de se produire, en termes de points. Cela nous permet d’interchanger des besoins en chemin dans la limite de contenu définie. Si nous pouvons rester dans cette limite, nous pouvons aussi rester dans des prix et durée fixes.
… Le client se plaint du prix ? Nous clarifions avec nos équipes de vente que la seule négociation possible dans cette situation est le tarif horaire. Nous ne mettrons pas en péril le projet en essayant d’augmenter la vélocité. Vous ne pouvez pas changer les membres de votre équipe en super-héros en changeant des valeurs sur une feuille de papier.
Une fois que vous faites signer le contrat et que le travail est en cours, il est impératif que vous managiez vos coûts. Dans mon article sur les Burndown Charts, je discute de comment ceux-ci peuvent être utilisés pour contrôler la vélocité de l’équip. Ils peuvent aussi être utilisés pour contrôler le changement de contenu et les coûts.
Un de mes secteurs de spécialisation est les Contrats au Forfait Agiles, et j’écris et présente sur le sujet régulièrement.
Pour des lecture complémentaires, regardez s’il vous plaît mon Guide to Agile Project Management.
Références
Winning the Battle but Losing the War
http://philipdiab.com/2011/09/winning-the-battle-but-losing-the-war/
par Philip R. Diab
Il y a quelques semaines nous avions un problème avec une livraison à domicile d’un restaurant. Il s’est avéré que la personne ayant pris la commande avait mal entendu et n’avait pas envoyé le bon plat à notre maison. Quand nous avons appelé le restaurant et avons discuté avec le Responsable du Service Client, il nous a informé qu’il avait écouté l’enregistrement de la commande et décidé que son collaborateur n’avait pas mal entendu la commande, mais plutôt que nous ne l’avions pas exprimé correctement. Il a non seulement refusé de rectifier la situation, il a au lieu de cela dit que c’était notre faute.
La chose étonnante pour moi est que c’est un établissement que nous utilisons régulièrement et il était stupéfiant que ce manager ne l’ait pas pris en considération. Ainsi, une erreur qui lui aurait très peu coûté n’a pas été réparée. Au lieu de cela cet établissement a perdu un habitué et l’argent dépensé dans cet établissement sur une base récurrente.
Le point est ici évident, Le Responsable Service Client a pensé qu’il agissait convenablement et dans le meilleur intérêt du restaurant. Il a effectivement gagné la bataille. Mais en nous importunant et nous faisant passer de clients à « non-clients », il a en fait perdu la guerre. Il a non seulement perdu un revenu futur mais il s’est retrouvé à devoir gérer une mauvaise presse quand nous avons informé notre réseau d’amis et associés de notre infortune.
Dans le management de projet il y a tout un ensemble de problèmes qui exigent notre intervention. On s’attend à ce que les chefs de projet soient orientés sur les détails pour qu’ils puissent indiquer d’où vient la faute sur n’importe quel problème donné afin d’y remédier convenablement. Le défi consiste cependant à ne pas oublier qu’il y a des impasses. Certes, nous pouvons établir que le client ou un certain groupe de parties prenantes ont eu tort. En outre, nous pourrions même faire payer ce groupe pour des changements de contenu, de coûts, ou de délais. Cela pourrait nous aider à sauver la face à court terme. Cependant, dans le long terme l’histoire est toute autre.
Il y a longtemps, un mentor m’a dit que quand vous opérez comme consultant la meilleure chose que vous puissiez espérer pour vous-même si vous vous disputez avec un client est de vous faire débarquer du projet. Même si cela peut être un peu extrême, je préconiserais certainement que pour protéger nos droits et ceux de nos organisations, nous devons garder une vue stratégique du résultat potentiel de ces types de problèmes.
Parfois nous pourrions trouver nécessaire de prendre à notre charge le faible coût d’un changement de contenu, bien que le client n’ait pas fourni de besoins appropriés et soit clairement en tort, pour s’assurer que la relation reste positive. Une approche équilibrée doit être imaginée par les chefs de projet pour garantir qu’ils prennent en compte les détails aussi bien que la vue à long terme.
Il n’y a aucune règle générale sur la façon de gérer ces situations. C’est pour beaucoup une approche ad hoc pour laquelle le chef de projet doit être préparé en comprenant la complexité des relations entre organisations. C’est comme tirer sur une corde où le PM doit deviner quand tirer sur celle-ci et quand lâcher un peu de mou.
Note perso: Comme le rappelle Garr Reynolds dans cette vidéo, la flexibilité du bambou peut être sa plus grande force…
http://philipdiab.com/2011/09/incentives/
par Philip R. Diab
Un des prérequis de succès sur tout projet est à mon avis les incitations. Les parties prenantes, spécifiquement le groupe d’usagers et clients doit avoir assez de motivations à supporter le livrable du projet, produit et/ou service. J’ai vu beaucoup de projets où une organisation a acheté une nouvelle solution logicielle ou une autre sorte de produit mais le groupe d’usagers n’a pas été correctement engagé pour assurer que le produit/service soit utilisé. Ceci n’arrive pas seulement dans des projets où un élément d’obtention de prime existe mais peut avoir lieu sur une variété d’initiatives.
Un exemple particulier qui me met en évidence le problème des primes est basé sur une expérience récente que nous avons eue avec la municipalité d’une ville dans laquelle nous vivons. Je vis dans une zone urbaine avec une variété d’immeubles d’habitation et des maisons familiales indépendantes. La communauté est configurée d’une telle façon que la collection d’ordures est faite via de grandes poubelles à ordures communes qui sont vidées par la ville dans ses camions sur une base quotidienne. Notre ville est par conséquent relativement propre, cependant elle n’aborde pas la question du recyclage comme partie intégrante de ses services.
J’étais heureux de voir il y a plusieurs semaines que la ville a initié un programme de recyclage qui tient en partie dans l’éducation et la prise de conscience et en partie une réorganisation des poubelles. Chaque immeuble/maison a reçu un avis selon lequel la ville leur enverra des poubelles de recyclage. En outre, la ville a publié une lettre qui explique comment le processus marchera et comment les diverses ordures seront ramassées.
Alors, après la dépense significative et l’effort mis dans le projet j’ai été étonné de voir que le jour où les nouvelles poubelles ont été livrées les vieilles sont restées en place. Comme je l’ai observé pendant la semaine suivante, j’étais à nouveau étonné que peu de voisins utilisent les nouvelles poubelles. En fait, chacun a continué les mêmes habitudes qu’auparavant. Ils amenaient leurs ordures aux vieilles poubelles, laissant les nouvelles propres et vides.
Ceci est pour moi un exemple parfait qui démontre que malgré l’éducation et l’engagement communautaire, le groupe de parties prenantes principales ne coopérait pas pour une raison simple : Pour cette communauté, il n’y avait aucune incitation à changer le comportement. Peut-être que des collaborateurs de la ville ont pensé que les nouvelles poubelles d’ordures étaient une motivation suffisante. Cependant, personne ne semble avoir pensé à supprimer les anciennes. Alors que nous nous associons souvent les incitations au potentiel de récompense des membres de l’équipe ou des parties prenantes s’ils exécutent certaines tâches ou se comportent d’une certaine façon, parfois les incitations doivent être concentrées sur le changement de l’environnement pour pousser les gens dans la bonne direction.
Il sera intéressant de voir comment la ville jugera du succès de ce nouveau programme, cependant, une pensée qui a traversé mon esprit est qu’ils faisaient peut-être un premier essai. En tant que tel ils ont décidé de laisser les vieilles poubelles jusqu’à ce qu’ils aient vu que la communauté était à l’aise avec les nouvelles.
Il est en effet difficile de spéculer et je n’ai pas l’intention de critiquer cette initiative importante, d’autant que j’ai pensé que c’est une étude de cas intéressante qui reflète ce qui arrive sur des projets, dont certains dans lesquels j’ai été impliqué.
http://www.projectsmart.co.uk/stop-scope-creep-running-away-with-your-project.html
Duncan Haughey, PMP
La dérive de contenu est une des raisons les plus communes pour laquelle les projets dépassent leur budget et livrent en retard. Souvent acceptés avec les meilleures intentions, les changements de contenu pendant un projet sont des événements négatifs qu’il vaut mieux éviter.
La plupart des chefs de projet se sont trouvés dans le cas où le client demande quelque chose à l’extérieur du périmètre accepté et s’attend à la voir incluse sans frais supplémentaires. En fait, ils agissent probablement comme si cela avait toujours fait partie du contenu.
La définition des limites d’un projet est difficile, mais sans une définition claire vous vous dirigez vers des problèmes.
La description du contenu est ce qu’un chef de projet s’engage à livrer tôt dans la vie d’un projet. Le contenu est défini pendant la phase d’analyse des besoins d’un projet. Travaillant étroitement avec le client et les utilisateurs, le chef de projet identifie ce qui est nécessaire pour atteindre les objectifs de projet. Le contenu de projet est enregistré dans la documentation de projet et agréé avec toutes les parties prenantes affectées.
Les causes majeures de dérive de contenu sont :
Jetons un coup d’œil à chacune plus en détail :
Le Problème :
Les clients ne savent pas toujours exactement ce qu’ils veulent et ont souvent seulement une vague idée. Le Syndrome « Je le saurai quand je le verrai ». L’échec de passer assez de temps à rassembler des besoins du business (ou assumer que l’on sait ce qui est nécessaire) peut mener à un besoin de ressources supplémentaires, un accroissement des coûts et des allongements de durées quand de nouveaux besoin apparaissent; en bref, une dérive de contenu.
La Solution :
Assurez que vous comprenez la vision de projet et passez du temps à documenter et agréer les objectifs de projet avec le client. Produisez un document de d’initiation de projet qui décrit les produits à livrer et le résultat. C’est une bonne idée de documenter ce qui est hors périmètre, aussi bien que ce qui est dans le périmètre, pour une absolue clarté. Agréez ce document avec le client, passez du temps pour le revoir en détail et demandez-leur de le signer. Ne poursuivez pas sans un accord ferme.
Le Problème :
Penser de vous savez ce que veulent les utilisateurs ou leurs besoins est une sérieuse erreur. Il est important de les impliquer dans les phases d’analyse des besoins et de conception. Plus ils ont d’engagement au début du projet, plus probablement cela vous évitera une dérive de contenu.
La Solution :
Impliquez vos utilisateurs depuis le début du projet, leur permettant de participer aux phases d’analyse des besoins et de conception; incorporez leurs suggestions et idées. Dans un projet de développement logiciel, documentez comment les utilisateurs interagiront avec le logiciel et développez des scénarios de test à utiliser plus tard. Agréez l’analyse des besoins et la conception avec toutes les parties prenantes du projet avant de démarrer la phase d’exécution.
Le Problème :
Le succès ou l’échec d’un projet peuvent souvent être prévus en regardant si des projets semblables ont été réussis par le passé.
Beaucoup de projets se heurtent aux problèmes parce qu’ils sont nouveaux dans leur industrie et n’ont jamais été réalisés auparavant. Personne ne sait à quoi s’attendre, il n’y a aucune leçon apprise et personne à qui demander. Dans ces circonstances, une dérive de contenu peut difficilement être évitée, causant des dépassements budgétaires et une livraison en retard.
La Solution :
Ces types de besoins de projet exigent d’avoir un degré de provisions pour aléas. Incluez certaines marges dans votre plan de projet afin de prévoir pour des problèmes et des événements imprévus et augmentez le budget pour représenter les ressources supplémentaires qui pourraient être nécessaires. Cependant, n’exagérez pas, être significativement en dessous du budget et livrer plus tôt est souvent considéré négativement.
Le Problème :
Vous pouvez vous attendre à un certain degré de risque de dérive du contenu dans la plupart des projets, donc il est important de concevoir un processus pour manager ces changements. Un processus simple consistant à documenter, considérer, approuver et trouver les ressources peut être conduit.
La Solution :
Introduisez un formulaire de contrôle des changements et un journal/registre des changements dès le début du projet. Expliquez leur utilisation au client et à l’équipe projet. Une requête de changement formellement écrite vous permettra d’évaluer le bénéfice business de tout changement et de rechercher son approbation éventuelle avant de l’inclure en tant qu’addition au contenu. Attachez un coût et une durée à chaque changement pour que le client comprenne bien son impact. Demander au client de passer par un processus formel aide à s’assurer qu’il y a une valeur claire pour le changement recherché.
Le Problème :
« Gold Plating » est le terme donné à la pratique d’excéder le contenu ou la qualité d’un projet en pensant que cela ajoute de la valeur. 
Dans des projets de développement logiciels, il n’est pas inhabituel pour des développeurs d’ajouter de nouvelles fonctionnalités croyant qu’elles augmenteront la satisfaction du client. Ces changements consomment du temps et du budget et ne garantissent pas d’augmenter la satisfaction client.
La Solution :
Assurez-vous que tous les membres de l’équipe sont pleinement conscients du contenu du projet et concentré sur livrer cela et rien de plus. Assurez-vous que le cahier des charges est suffisamment détaillé pour éviter toute ambiguïté qui pourrait mener à du travail inutile.
Récompensez des membres de l’équipe pour livrer selon la spécification, à l’heure et dans le budget. Précisez que des fonctionnalités non documentées ne devraient pas être ajoutées, mais passées par le processus de contrôle des changements.
S’il y a du temps et qu’il reste de l’argent à la fin du projet, laissez le client décider que faire.
Pour récapituler, assurez-vous que vous positionnez correctement les attentes au début du projet, travaillez étroitement avec les utilisateurs pour définir clairement ce qui est dans et hors du périmètre. Enregistrez-le dans le document d’initiation de projet. Cependant, ne supposez pas que le client lira et comprendra ce document. Passez du temps avec le client à le revoir pas à pas et à vous assurer qu’ils comprennent et acceptent le contenu. Ne continuez pas sans accord ferme.
Souvent il n’est pas possible d’éviter que le contenu augmente pendant un projet, particulièrement s’il y a une bonne raison business de le faire. Cependant, il doit être géré correctement. Concevez un processus de contrôle des changements pour vous assurer que tous les changements sont correctement documentés, considérés, approuvés et approvisionnés en ressources. Note : Si le budget et la durée sont augmentés avec le contenu, habituellement, on ne considère pas le changement comme une dérive de contenu.
Alternativement, vous pouvez vouloir empêcher que des changements soient ajoutés petit à petit pendant le projet et pouvez décider de les documenter mais pour une phase ultérieure. Cela permet à la phase acceptée d’être livrée à l’heure et dans le budget et aux changements d’être managés et dotés en ressources séparément.
Si vous considérez que seulement 32 % ¹ de tous les projets réussissent pleinement; alors vous êtes mieux lotis à dépenser votre temps à livrer par rapport aux besoins acceptés en début du projet et à éviter la « sur » qualité.
La dérive de contenu cause beaucoup d’échecs de projet; en prenant quelques mesures simples vous pouvez vous assurer qu’elle n’affecte pas les vôtres.
¹ The Standish Group International, Inc. CHAOS Summary 2009. Boston, MA 02109: The Standish Group International, Inc., 2009.
Stephen Carver, conférencier à Cranfield, a dirigé un groupe de travail interactif sur le management des exigences de projet et il est parvenu à d’excellentes conclusions en pensant hors des chemins habituels ! Son analogie entre l’aviation et le management de projets et de programmes est particulièrement pertinente et je suis certain que vous saurez en faire bon usage.
Alors, vous entez-vous davantage pilote de ligne, de chasse ou plutôt contrôleur aérien envers les projets que vous managez ?
Le premier billet lu sur PMI Community m’a rappelé combien il est difficile pour tout un chacun de changer ses habitudes et comportements. Le second sur Zen Habits propose une approche pour créer une nouvelle habitude. Et la petite vidéo d’introduction que j’ai insérée nous rappelle la nécessité de persister pendant plusieurs semaines (5 semaines si je me souviens bien selon une étude d’une Université américaine) avant qu’un changement devienne une habitude. Donc, commencez dès aujourd’hui à implémenter un changement qui vous tient à cœur, même minime comme tenir une liste des choses à faire que l’on mettra à jour chaque soir, tenez bon pendant 5 semaines et ce sera devenu une habitude qui vous demandera bien moins d’efforts qu’au début.
Le projet est très souvent synonyme de changement: processus de travail, organisation, outils, produits, services… Lorsque vous devez changer les habitudes de vos clients et/ou utilisateurs sur votre projet, il faudra plusieurs jours, semaines, mois peut-être avant que le changement que vous apportez avec votre projet ne devienne pour eux qu’une partie « normale » de leur vie.
http://www.pmi.org/eNews/Post/2011_07-08/nlu_change_behavor.html
Jack S. Duggal, MBA, PMP
Le changement comportemental est difficile, même quand c’est une question de vie ou de mort.
Seulement un sur sept patients cardiaque parvient à changer son comportement, même quand les docteurs leur disent qu’ils mourront s’ils ne le font pas, selon une étude référencée par Robert Kegan et Lisa Laskow Lahey dans leur livre « Immunity to Change » [Harvard Business School Press, 2009].
En tant que chef de projet, vous constaterez aussi que le changement est difficile pour presque tout un chacun.
Vous pouvez interviewer des parties prenantes, conduire des phases pilotes et obtenir des retours d’information pour un projet qui par exemple change une interface utilisateur opérationnelle et il va probablement y avoir beaucoup de résistance.
Comment pouvez-vous assurer le succès de projet quand il dépend du comportement d’autres personnes ?
Voici quelques astuces pour vous aider à motiver les personnes à changer leur comportement et adopter nouveau Processus.
Chaussez les bottes (ou pantoufles) de vos utilisateursUn simple interview ou discussion avec vos utilisateurs ne suffit pas à causer un changement comportemental.
C’était la situation quand un hôpital a embauché des consultants de conduite de projet pour améliorer l’expérience des patients. Dans ce scénario, les consultants n’ont pas interviewé ou examiné les patients. Au lieu de cela, les consultants se sont faits inscrire comme patients et ont dormi dans des lits de patients pendant 24 heures avant de proposer des modifications aux procédures existantes.
Vous devez faire le même dans n’importe quelle sorte de projet. Chaussez les chaussures de votre utilisateur. Ressentez leur douleur. Voyez des choses de leur perspective. Comprenez ce qui est vraiment important pour eux.
Alors, ils pourraient être plus enclins à accepter et adopter le changement.
Les personnes sont souvent trop occupées pour prêter attention à de nouveaux processus ou des changements de procédures.
Une société d’e-commerce, par exemple, a cherché à mettre à jour son interface opérationnelle. Cela a impliqué de créer de nouveau flux de travail et processus.
Le changement proposé était important et les chefs de projet savaient qu’ils devaient le communiquer aux collaborateurs d’une façon appropriée. Ils avaient besoin d’attirer l’attention des utilisateurs et les atteindre sur un niveau émotionnel pour stimuler un changement comportemental.
Les utilisateurs ont été invités à un feu de joie pour brûler tous les vieux manuels de processus. Cela a capté avec succès leur attention d’une façon visuelle et émotionnelle et a motivé leur changement.
En planifiant un changement de processus ou procédure, assurez-vous que le changement est équitable et bon. Pour aider des utilisateurs à adopter ce changement, concentrez-vous sur les quatre Es:
Apprenez-en davantage sur la justification du changement dans Project Resistance? Provide Justice, un article publié dans Community Post l’été dernier.
Mesurez ce qui importeLes mesures pilotent le comportement. Quand vous avez choisi des mesures appropriées et démontré leurs effets, vous pouvez obtenir un impact soutenu sur le changement comportemental.
Par exemple, une organisation a constaté que ses collaborateurs passaient trop de temps dans trop de réunions inefficaces. Les collaborateurs avaient aussi l’habitude de ramener du travail à la maison le soir parce qu’ils n’avaient pas assez de temps pendant la journée pour le compléter.
Les chefs de projet étaient chargés d’un projet afin de changer ce comportement.
D’abord, ils ont mesuré le temps et le coût de chaque collaborateur qui participaient à des réunions régulières. Puis, les chefs de projet ont visuellement affiché ces données et ont montré comment elles avaient un impact sur la productivité.
Quand les résultats du projet ont été présentés, les chefs de projet se sont sentis confiants que les personnes changeraient leur comportement pour conduire des réunions en moins grand nombre, plus courtes et plus efficaces en se basant sur ces données et ces mesures.
1. Préparer un plan. Oubliez les échecs passés, donnez-vous une date et partez de zéro avec un plan robuste.
2. Choisissez un déclencheur. Un déclencheur est un évènement qui lance cette nouvelle habitude et qui si possible vous la rappellera chaque jour.
3. Recevez des feedbacks positifs. Il est facile d’abandonner sans support. Vous devez vous félicitez de vos efforts et vous encouragez vous-même quand c’est difficile en vous rappelant les bénéfices que vous allez tirer de cette nouvelle habitude.
4. Parlez de votre nouvelle habitude sur un groupe social. Annoncez-la sur Twitter, Facebook, ou votre blog. Demandez à vos amis et famille de vous supporter. Demandez leur de vous rappeler votre décision et votre responsabilité.
5. Donnez-vous des récompenses. Elles renforceront votre détermination.
http://blogs.pmi.org/blog/voices_on_project_management/2011/04/prioritizing-agile-project-req.html
par Bill Krebs
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode est le modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
http://ecaminc.com/index.php/blog/59-generalblog/237-2011-02-28
Le management invente de grands plans pour introduire le changement, il met en œuvre ces plans et trois ans plus tard l’organisation est redevenue telle qu’elle l’était avant l’initiative. Le changement vers de nouveaux systèmes révolutionnaires n’est pas facile; maintenir ces processus et procédures est beaucoup plus difficile. La raison pour laquelle des idées progressistes peuvent connaître une mise en œuvre réussie seulement pour voir l’organisation régresser à son état antérieur quelques années plus tard prend ses racines dans les pratiques sociales et la nature humaine.
Réussir un changement dans l’entreprise exige une charte de management, du financement pour l’éducation, une démonstration par l’exemple et une intégration dans le tissu qui fait l’entreprise. Toutes ces choses ont leurs racines dans le management. La genèse de l’idée peut venir de tous les coins de l’organisation, mais le management doit parrainer et supporter le changement par des actions, et pas seulement des paroles.
Le changement est difficile et les chances de l’implémenter avec succès les meilleurs changements sont très faibles. L’organisation entière participe à la mise en œuvre du changement; cependant, le management porte la responsabilité de le faire se produire. Sans engagement total du management derrière l’initiative, elle échouera. 
Le succès est obtenu de haute guerre et atteint seulement par les meilleurs. Les managers qui le réalisent doivent en récolter une récompense significative.
La plupart des leaders qui pilotent le changement trouvent peu d’intérêt dans la tâche banale d’entretien du processus. Ils ont besoin du prochain défi. La culture d’entreprise induit ceci par les promotions. Les primes financières aident, mais la stature d’un nouveau titre ou d’un nouveau bureau expose la réussite à tous. Si la récompense est disproportionnée par rapport aux buts de l’agent de changement, il ou elle cherchera de nouvelles opportunités à l’extérieur de l’organisation courante. Quand bien même, peu de temps après que l’on ait considéré le changement réussi, les personnes responsables de cet accomplissement quittent nécessairement sa sphère d’influence. Ajouter à cela l’afflux normal de nouveaux salariés, tous ayant le besoin de recevoir une formation dans ces concepts non usuels, le tissu de l’entreprise autour du changement commence à s’effilocher. Le désir de confort accroît une pression passive-agressive sur le système le ramenant rapidement à son état original.
Récemment un leader bien respecté, visionnaire et dynamique que je connais a quitté une organisation qu’il avait dirigée depuis beaucoup d’années. Pendant son mandat, il avait fait des changements significatifs. Les accomplissements comprenaient la transformation du groupe de développement d’applications informatiques en une équipe bien réglée et très performante. Cette équipe cultive et embrasse encore le changement. Un des nombreux changements complétés était de passer d’une méthodologie de management de projet en cascade pour le développement applicatif à une approche agile. Beaucoup de managers ont eu du mal à comprendre la valeur d’échouer tôt et que la liste des choses commencées au début de l’année n’était pas nécessairement la liste complétée à la fin de l’année. Leurs méthodes testées et prouvées de mesure du succès étaient périmées. Dans ce nouveau paradigme, une année réussie pourrait ne rien livrer si les équipes décidaient dans de premières itérations qu’il y avait une valeur insuffisante pour le business. 
Il reste à voir si la nouvelle direction, peu familière avec agile, sans parler de l’informatique, continuera à utiliser agile. Cela empirera quand la société embauchera d’autres nouveaux membres dans l’équipe et que les dépenses de formation augmenteront. Le management « court-termiste » considère la formation comme une cible quand il essaie de réduire des frais généraux.
Le nouveau leadership doit regarder le système dans son ensemble, au lieu d’essayer d’économiser quelques centimes de chaque pièce prise individuellement.
C’est dans la nature humaine que de résister au changement. La norme réconforte. Chacun d’entre nous s’y oppose inconsciemment et quand la pression pour le maintenir diminue, nous dérivons en arrière vers nos anciennes habitudes. C’est encore renforcé quand nous sommes jetés dans un environnement étranger qui a besoin d’action rapide. Nous recourons à ce qui est testé et prouvé, des processus et les procédures confortables à mettre en œuvre de notre passé. Ces actions pourraient remplacer les solutions nouvelles et innovatrices qui nous sont peu familières et dont nous ne comprenons tout simplement pas la valeur.
Nous devons faire une pause et comprendre les environnements dans lesquels nous opérons et ne retourner en arrière que quand il y a preuve d’échec.
DantotsuPM.com 