Étiquette : risques

les dépendances entre les risques

Le par mopertodans best practices1 commentaire

Dependencies Between Risks par Brad Egeland

http://pmtips.net/dependencies-risks

Ah les « et si… » …

Et si nos délais de projet n’avaient aucune contrainte ? Et si nous avions tous les besoins soigneusement définis devant nous sans aucun détail manquant à chaque fois et sur chaque projet ? Et si nous n’avions aucune contrainte de ressource, aucune ratée de nos fournisseurs, aucun client essayant de demander plus de fonctionnalité ‘ seulement pour cette fois ‘ ? Et s’il n’y avait aucun risque sur nos projets ?  …comme si cela allait se produire.

Et si les chefs de projet avaient un financement illimité, ils pourraient toujours identifier une multitude d’événements de risque. Certains des impacts de ces risques peuvent être insignifiants, tandis que d’autres peuvent exposer le projet à de sévères dangers. Avec un grand nombre d’événements de risque possibles, il est impossible d’adresser chaque situation. Il peut s’avérer nécessaire de prioriser les risques.

Supposons que le chef de projet catégorise les risques selon le calendrier, le coût et les contraintes de performance du projet. Supposons, pour le moment que vous utilisez un outil détaillé comme Seavus’ Project Viewer pour vous aider à gérer l’échéancier de projet et que cet échéancier est la première priorité pour ce projet. Si l’échéancier a été déterminé comme étant la priorité la plus haute pour le projet, le chef de projet devrait concentrer ses efforts en premier sur la réduction des risques de planification. La priorisation des risques pourrait être établie par le chef de projet, par le sponsor de projet, ou même par le client. La priorisation des risques peut aussi être spécifique à l’industrie – ou même au pays. Il est fort peu probable qu’une méthodologie de management de projet dicte la priorisation des risques. Il est simplement impossible de développer une standardisation dans ce domaine qui puisse être uniformément appliquée à tout projet.

La priorisation des risques pour un projet individuel est un bon point de départ et pourrait bien fonctionner s’il n’y avait le fait que la plupart des risques sont corrélés. Nous savons de l’analyse des options qu’une modification d’échéancier va probablement induire des changements de coût et de performance. Donc, bien que l’échéancier bénéficie de la plus forte priorité dans notre exemple, la réponse aux événements de risque de délais peut causer l’évaluation immédiate des événements de risque de performance techniques. Les risques sont en corrélation.

Aussi n’oublions pas que des opportunités de projet, à leur tour, peuvent causer des risques supplémentaires pour le projet. Autrement dit, les stratégies de réduction de risque qui sont conçues pour bénéficier d’une opportunité pourraient créer un autre événement de risque qui serait plus sévère. Par exemple, faire des heures supplémentaires (une opportunité que l’on peut vouloir exercer sur la plupart des projets) pourrait vous économiser 15,000 $ en compressant l’échéancier de projet. Mais si les collaborateurs font plus d’erreurs pendant les heures supplémentaires, de nouveaux tests peuvent être exigés, des matériels supplémentaires peuvent devoir être achetés et un dérapage de délais pourrait bien des produire, causant ainsi une perte de 100,000 $. Donc, cela vaut-il la peine de risquer une perte de 100,000 $ pour en gagner 15,000 $ ?

Pour répondre à cette question, nous pouvons utiliser le concept de valeur attendue/escomptée, en supposant que nous puissions déterminer les probabilités associées aux erreurs faites et le coût de ces erreurs. Sans aucune connaissance de ces probabilités, les actions prises pour réaliser les opportunités seraient dépendantes de la tolérance au risque du chef de projet.

La plupart des professionnels de management de projet semblent reconnaître que les risques les plus sérieux et ceux que nous semblons connaître le moins, sont les risques techniques. La pire situation est d’avoir de multiples risques techniques qui interagissent entre eux de façon imprévisible ou inconnue.

Bien que les méthodologies de management de projet fournissent une structure pour le management des risques et le développement d’un plan de gestion des risques, il est fortement peu probable qu’une méthodologie soit assez perfectionnée pour représenter l’identification des risques de dépendance technique. Le temps et le coût associé à l’identification, la quantification et le traitement des dépendances de risques techniques pourraient sévèrement impacter le projet sur le plan financier.

Kerzner on Strategic Planning for PMUne autre interdépendance critique est la relation entre le management des changements et la gestion des risques, qui font tous les deux partie de la méthodologie de management de projet. Chaque stratégie de management des risques peut aboutir à des changements qui produisent des risques supplémentaires. Risques et Changements vont de pair, ce qui est une des raisons pour lesquelles les sociétés intègrent d’habitude le management des risques et des changements dans une méthodologie unique. Si les changements ne sont pas bien gérés, plus de temps et argent sont nécessaires pour exécuter le management des risques. Et ce qui rend la situation encore pire est qu’il faut des salariés à plus forts salaires et davantage de temps pour évaluer les risques supplémentaires résultant de changements non managés. Les changements bien managés, à l’inverse, permettent de développer un plan de management des risques moins onéreux.

Les méthodologies de management de projet, quelque soit leur qualité, ne peuvent pas précisément définir les dépendances entre les risques. C’est d’habitude la responsabilité de l’équipe projet de faire ces déterminations.

Les informations de cet article ont été tirées, en partie, du livre de Kertzner “Strategic Planning for Project Management….”

CSP Formation
Partenaire de DantotsuPM

manager les opportunités dans le Projet

Le par mopertodans best practicesLaisser un commentaire

Project Opportunity Management

http://www.esi-intl.co.uk/horizons/publication/2011/201106_oppman.asp?horp=null

Quand on demande comment les exercices de management des risques sont typiquement conduits, la plupart des chefs de projet répondent que cela implique des conversations et de la documentation autour des événements de risque et leurs probabilités et impacts respectifs. Bien que ceci soit un exercice nécessaire et bénéfique, cette approche standard et cet état d’esprit ne prennent pas en compte le temps pour reconnaître et se concentrer sur maximiser les opportunités et ils mènent souvent l’équipe et le chef de projet dans la direction opposée. Un management des risques efficace ne devrait pas être concentré seulement sur l’identification de points d’échec possibles, mais aussi sur apprendre comment reconnaître et exploiter au mieux des opportunités d’assurer le succès tant du projet actuel et du futur. Le management d’opportunités c’est supprimer les barrières et créer un chemin vers le succès pour vous et vos équipes.

Assurez-vous que vous créez du temps non seulement pour identifier et traiter avec les risques, mais aussi reconnaître et exploiter des opportunités dans vos projets. Il y a de grandes chances que ce changement de perspective vous permette de voir de multiples opportunités qui pourraient ne pas apparaître autrement.

Voici six opportunités sur lesquelles presque tout chef de projet, indépendamment de la discipline, peut et doit capitaliser.

1. Saisir l’opportunité de reconnaître et récompenser le succès.

Des projets réussis sont toujours le résultat d’équipes gagnantes. Des équipes gagnantes sont le résultat de la collaboration et des efforts d’individus motivés et doués. Le chef de projet doit maximiser toutes les opportunités de reconnaître et récompenser le succès de l’équipe. Cela peut être difficile dans le marché actuel étant donné l’accent énorme pesant sur les budgets et les dépenses. Dans des conditions économiques difficiles, ne sous-estimez pas l’importance du retour d’information individuel en direct.

2. Saisir l’opportunité de donner et demander un retour d’information.

Le retour d’information est une opportunité incroyablement puissante, cependant souvent oubliée qui peut être utilisée avec des pairs, ses employés, ses fournisseurs et la direction aussi. Beaucoup de chefs de projet réalisent l’importance du retour d’information fourni aux directeurs fonctionnels, mais échouent à maximiser les opportunités qui peuvent résulter de la demande de retour d’information. La chose importante à garder est à l’esprit que les gens se souviennent toujours de comment ils ont été traités et de leur ressenti, longtemps après que les chèques cadeaux d’American Express aient été dépensés. Nous, chefs de projet, sommes dans une position unique pour fournir aussi bien critique constructive qu’éloge aux membres de l’équipe et à leur management fonctionnel. C’est la responsabilité du chef de projet de se bouger pour les membres de l’équipe et s’assurer que leurs meilleurs intérêts sont représentés. Veuillez lire ESI Horizon’s article “The feedback-six pack” pour informations et idées complémentaires sur le retour d’information.

3. Saisir l’opportunité de partager avec des chefs de projet professionnels dans votre domaine sur les leçons apprises.

La plupart des chefs de projet professionnels ne sont pas timides vis-à-vis du partage de leçons apprises sur les opportunités qu’ils ont maximisées et celles qu’ils ont manquées en chemin! Saisissez l’opportunité de partager vos expériences aussi bien qu’apprendre de celles d’autres. Des chapitres PMI locaux, des groupes d’intérêt spécifiques et LinkedIn sont quelques-unes des nombreuses manières de l’accomplir. Ces leçons Project Management Instituteapprises pourraient très bien être le résultat d’un retour d’information du numéro deux, ci-dessus!

4. Saisir l’opportunité d’utiliser et impliquer le senior management et votre sponsor.

Ne sous-estimez jamais la valeur du sponsor de projet quand il s’agit d’éliminer des obstacles pour faire avancer les choses. Les gens ont tendance à écouter un peu plus attentivement quand la direction parle. Permettez-leur d’être engagés et de vous assister dans la suppression de barrières et obstacles. L’initiation de projet est aussi un bon moment pour avoir de franches conversations avec la direction sur leur vision pour le projet aussi bien que les opportunités qu’ils entrevoient. Cela vous permettra aussi à l’occasion de mettre en évidence les progrès et la capitalisation sur ces opportunités aux réunions de statut de projet.

5. Saisir l’opportunité de reconnaître les frontières culturelles, calendriers internationaux et différences culturelles, etc.

La plupart des équipes de nos jours sont un véritable creuset de cultures et mélange de fuseaux horaires. Donc, communiquer et déterminer un temps acceptable pour tous dans l’équipe pour les réunions offrent beaucoup de défis et opportunités. Le chef de projet devrait saisir l’occasion de construire une relation avec les membres de l’équipe internationale et les parties prenantes en apprenant sur les vacances internationales et en travaillant en dehors des heures ouvrées pour accommoder les fuseaux horaires de différents pays.

6. Encourager le management des opportunités dans vos équipes.

Cela manifeste à l’équipe que vous estimez non seulement leur contribution, mais êtes aussi enclins à la reconnaître et en faire usage pour le succès du projet. Chacun a des perspectives et des idées uniques quant aux opportunités dans le projet. Souvent, tout ce que vous devez faire est demander.

Exploiter ces six opportunité aidera le chef de projet à construire une relation avec l’équipe aussi bien que fournir des informations de valeur et opportunes au-delà des exercices conventionnels de management de risque au chef de projet et à l’équipe.

attention aux mirages de sécurité…

Le par mopertodans forum de discussionLaisser un commentaire

Le sentiment de sécurité ne correspond pas toujours la réalité, nous dit l’expert en sécurité informatique Bruce Schneier. Il explique pourquoi nous dépensons des milliards à adresser de nouveaux risques potentiels qui font la une des journaux, comme avec « le cinéma autour de la sécurité » de votre aéroport favori, alors que nous négligeons des risques bien plus probables. Bruce explique aussi comment nous pouvons casser ce modèle.

Je retiens de son intervention à TED, en particulier, la distinction qu’il convient de faire entre le sentiment de sécurité et la réalité et combien ces 2 vues d’un même risque peuvent être décalées. Décalage parce que nous ne sommes tout simplement pas très doués pour prendre des décisions rationnelles en matière de sécurité. Nous avons en effet un biais naturel à exagérer l’importance ou l’impact potentiel de risques inconnus ou avec lesquels nous ne sommes pas familiers. Nous surestimons souvent les risques lorsque nous ne sommes pas en situation de contrôle. Nous avons aussi tendance à répondre davantage aux histoires qu’aux données. Et, il faut reconnaître que nous ne sommes pas très doués pour gérer les grands chiffres mais plus habiles avec les petits. D’autre part, toute information qui viendra confirmer notre idée sera mieux appréciée (mais pas forcément à sa juste valeur) qu’une autre qui va à l’encontre de ce que nous pensons tenir pour certain.

Une très intéressante vidéo, donc, que je vous recommande.

Pour ceux qui souhaitent aller plus loin sur ce sujet, j’ai trouvé des pointeurs intéressant dans la revue Management de Mai 2011 (Pages 84-86) avec un article intitulé « Déjouez les pièges que vous tend votre cerveau ».

Y sont mentionnés les travaux du psychiatre Aaron Beck et des psychologues Amos Tversky et Daniel Kahneman sur le rôle des « biais cognitifs » ainsi que les livres « C’est (vraiment) moi qui décide? » de Dan Ariely (dont vous trouverez ici une vidéo sur notre capacité à prendre des décisions), « Le cygne noir, la puissance de l’imprévisible » de Nassim Nicholas Taleb, et « Quand les grands patrons se plantent » de Sydney Finkelstein.

Mettez un peu de management de risques dans votre moteur « projet »

Le par mopertodans outils et méthodes3 commentaires

Mettez un peu de management de risques dans votre moteur « projet »

un billet de Marc Burlereaux

Membre Fondateur du PMI® Pôle des Pays de Savoie

Certifié PMI-RMP® Risk Management Professional

Un sondage organisé par l’association PMI® (Project Management Institute) a indiqué que 54% des projets finissent soit  dans les temps prévus, soit selon le budget convenu, mais rarement les 2 en même temps…

Nous parlons ici de projets au sens large. Si l’on se limite aux seuls projets informatiques qui peuvent être plus « risqués » que d’autres types de projets reposant sur un savoir-faire deux fois millénaire comme ceux de la construction,  les statistiques peuvent être différentes … Remarquez qu’une de mes connaissances me disait que lors de la construction de sa maison le budget initial avait été largement dépassé par les nombreux avenants , ce qui devrait rappeler des souvenirs douloureux à nombre d’entre vous …

Ce sondage PMI® indique également que la méthodologie la plus utilisée par les organisations « à hautes performances » en management de projets est le management des risques … à hauteur de 88% des réponses …

Et si nous nous intéressions au management des risques pour améliorer les résultats des projets ?

Livrer en temps et heure un produit qui correspond aux attentes du client selon le budget et la qualité convenue : est-ce une utopie ?

J’entends déjà certains d’entre vous « que va nous vendre ce beau parleur ? » Et aussi : « d’abord ce n’est pas mon problème, je ne suis pas à la tête d’une multinationale qui se dote d’outils sophistiqués pour gérer de nombreux projets ! »

Reprenons l’exemple de la construction de la maison : ne pensez-vous pas rétrospectivement qu’un « mini » management des risques aurait pu éviter quelques déboires ?

Comme par exemple :
  • un meilleur examen des références et du bilan de votre constructeur
  • une réflexion approfondie sur les risques induits par les solutions novatrices (dans mon cas personnel j’ai choisi une solution de chauffage novatrice en 1992, la géothermie au fréon … gaz qui troue la couche d’ozone …)
  • l’anticipation d’une solution de secours en cas de déficience d’un de vos artisans
  • la prévision d’une réserve financière pour les … nombreux … avenants (je recommande de particulièrement faire attention à l’électricité et les luminaires …) pour ne pas se retrouver à faire le tour de la famille pour boucher les trous.

Certains me rétorqueront : «Mais  j’ai déjà un responsable sécurité et logistique qui gère les polices d’assurance, le risque incendie avec la commission de sécurité et autres catastrophes naturelles, alors quoi d’autre ? »

C’est bien, mais ce n’est pas le même sujet. S’il est important de gérer le risque au niveau de l’entreprise, il est aussi important de sensibiliser les équipes projet au management du risque : que ce soit pour un projet informatique, pour le lancement d’un produit, pour le réaménagement de vos locaux, l’installation d’une succursale à l’étranger, la volonté d’exporter en Chine, …. Je ferai à ce sujet une double remarque : les risques « entreprise » sont à prendre en considération dans les risques projets et les risques projets peuvent avoir un impact de taille sur l’activité de l’entreprise : un projet informatique ayant pour objectif de remplacer le cœur de votre système d’information qui  échoue le jour du démarrage a un impact vital pour la poursuite de vos activités, si une solution de secours n’a pas été prévue. Il est même conseillé de consolider les risques projets au niveau de l’entreprise pour une maîtrise et une prévention globales de leurs impacts.

PMI-RMP®, PMI® are registered mark of Project Management Institute, Inc.

Que faire alors ?

La prise de conscience est déjà une première étape !

Ensuite, former une partie de son personnel, en ayant par exemple un « champion du risque dans le management des projets » qui portera la bonne parole.  Se faire assister de manière ponctuelle peut aussi être une solution pour lancer ou consolider la démarche de management des risques dans les projets.

Enfin en tant que responsable, supporter, promouvoir/soutenir cette approche de manière pragmatique afin de s’assurer du succès de la démarche.

Quels sont les étapes principales à suivre ?

Commençons par la définition du risque « un évènement incertain qui s’il arrive a un impact positif ou négatif sur les objectifs du projet ».

Je commence à dessein par le risque engendrant un impact positif ou « opportunité » : c’est très courant d’oublier cet aspect, ou alors on le fait de manière implicite. Mais le fait de commencer par lister avec l’équipe les opportunités potentielles du projet, qui par nature sont incertaines, permettra de mettre en place des actions qui favoriseront l’émergence de ces opportunités. Par exemple, cela pourrait être l’opportunité d’utiliser une nouvelle forge logicielle* dans le domaine du développement logiciel qui économisera du temps en phase de codage et de tests ou alors, de trouver d’autres clients intéressés par l’outil en cours de développement pour augmenter le retour sur investissement.

Examinons maintenant les différents processus du management des risques :

  • planification du management du risque, en définissant notamment la méthode et les définitions
  • communication autour du management du risque, peut-être le point le plus important
  • analyse des risques :
  • identification (quels sont les risques ?)
  • qualification des risques (définir « l’impact » et la « probabilité » de chaque risque et leur priorité)
  • préparation des plans de secours ou de contingence, y compris des budgets de réserve
  • suivi des risques tout au long du projet (mettre à jour de manière continue la liste des risques et leurs priorités  (de nouveaux risques peuvent surgir comme d’autres peuvent disparaître), et être capable de présenter la liste des risques prioritaires : leurs impacts et les plans de contingence
  • clôture de la démarche (tirer les leçons apprises en vue de l’amélioration continue).

Voici quelques conseils qui me paraissent essentiels :

1.       Planification :

Cette étape est vitale car elle permet de :

  • définir la méthode à appliquer et surtout l’adapter  à la taille de l’entreprise et du projet,
  • formaliser les définitions de base pour une compréhension commune à tous,
  • définir le suivi des risques et les canaux de communication.

Si l’entreprise a déjà effectué cette démarche pour d’autres projets, il suffira de l’ajuster au projet concerné. Sinon, la personne en charge du projet aura un rôle de pionnier et devra définir beaucoup de choses. Je conseille à cette personne de suivre une formation ou de s’adjoindre l’appui d’un consultant en management de projets.

2.       Communication :

Pour l’illustrer je vais utiliser la règle des 3 C :

  • Communiquer : en vendant à l’équipe et aux parties prenantes (client, sponsor, partenaires…) le management des risques et ses plus-values dès le début du projet
  • Communiquer : en s’assurant que tout au long du projet de nouveaux risques émergent et documenter les actions prises suite à ces risques qui se sont transformés en problèmes réels; le management du risque doit faire partie du suivi hebdomadaire du projet
  • Communiquer : en veillant à une communication pertinente et ciblée à la structure hiérarchique sur l’évolution des risques et de leur prise en compte
3.       L’analyse :

Lors de la phase d’identification :

  • S’assurer de la bonne formulation du risque : la cause (fait ou condition) de déclenchement du risque (incertain sinon c’est déjà un problème) ayant un effet (résultat potentiel qui peut être positif ou négatif)
  • Réunir les bons interlocuteurs pour réfléchir aux risques potentiels et notamment les équipes opérationnelles Réfléchir aux catégories de risque peut permettre de ne pas en oublier … mais attention à ne pas se limiter aux catégories existantes sous peine de  limiter la créativité
Lors de l’analyse des risques :
  • Choisir une échelle de 1 à 10 pour qualifier l’impact et la probabilité des risques
  • Chaque risque aura ainsi un poids = probabilité x impact qui permettra ainsi de les prioriser afin de déterminer ensuite une action pour les plus prioritaires et de garder un œil sur les autres risques moins prioritaires sans les adresser directement
  • Ne pas confondre impact et probabilité et les évaluer de manière séparée. Si l’impact d’un risque (ou son effet) est élevé cela ne veut pas forcément dire que la probabilité qu’il se réalise soit élevée. Dans le cas de la tempête Xynthia, si les conséquences furent dramatiques (fort impact), par contre la probabilité de la conjonction de plusieurs risques était faible car il est rare de réunir de telles causes : la violence de la tempête et la surcote de 1m50 dues à trois facteurs, de forts coefficients de marée, l’influence du creusement dépressionnaire, agissant comme un « aspirateur » soulevant l’océan, et l’effet des vents de surface poussant la houle vers le littoral.  Le poids de ce risque par sa gravité, même si la probabilité était faible, aurait nécessité la préparation d’un plan de contingence plus énergique, comme l’évacuation préventive des villes de La Faute sur mer et la Tranche.
  • Définir l’élément déclencheur qui annonce la matérialisation du risque
4.       La planification des réponses à apporter si le risque se réalise (plans de contingence)
  • Adresser les risques les plus prioritaires
  • Établir des réponses de manière active afin de minimiser les impacts des menaces ou risques négatifs sur les objectifs du projet
  • Éliminer le risque en décidant, par exemple de ne pas livrer un des composants d’un produit dont le développement est trop risqué,
  • Réduire le risque en ayant, par exemple un personnel polyvalent pour faire face à des défections,
  • Transférer le risque en s’assurant ou en sous-traitant, par exemple à une autre entreprise qui possède le savoir-faire
  • Penser aussi aux opportunités, les risques qui engendrent un impact positif
  • Exploiter l’opportunité, en allouant par exemple plus de ressources expertes sur le projet et ainsi améliorer la qualité du produit livré,
  • Partager l’opportunité, par exemple en développant une relation d’affaires avec un partenaire déjà implanté dans le pays que vous visez
  • Améliorer l’opportunité, par exemple en créant des conditions favorables à la réussite de votre projet
  • Si le coût de la réponse envisagée pour réduire ou éliminer un risque est plus élevé que l’impact estimé, cette réponse doit-elle être retenue ou doit-on accepter le risque ? La réponse sera souvent non.
  • Un bon plan de réponse d’un risque devrait contenir
  • Les actions convenues à l’avance
  • Le calendrier de ces actions
  • La personne en charge de dérouler et contrôler le plan d’action
  • Le plan de secours si les effets de l’action ne sont pas concluants
  • Les risques résiduels, risques qui ne seront pas éliminés par le plan d’action
  • Le ou les éléments déclencheurs
  • Les échéances de revue du risque
  • Prévoir un budget de réserve pour les risques non anticipés
5.       Le suivi :
  • Mettre le management des risques à l’agenda de chaque revue de l’avancement du projet
  • Mettre à jour la liste des risques en intégrant les nouveaux risques et en réévaluant les risques existants
  • Examiner les évènements déclencheurs des risques non encore réalisés
  • Décider la mise en place d’une réponse si un évènement déclencheur se manifeste
  • Surveiller les effets d’une réponse à un risque
  • Présenter au management la liste des 3 ou 5 risques majeurs
6.       La clôture :
  • Revoir les points positifs sur lesquels capitaliser pour un usage futur
  • Lister les points d’amélioration à rectifier
  • Déterminer la plus-value du management des risques dans la réussite du projet

Voici quelques éléments qui, je l’espère, vous sensibiliseront au management du risque et vous permettront d’envisager les actions au sein de votre organisation pour les intégrer à votre management de projets et ainsi favoriser leur réussite. En effet, la gestion des risques n’est pas l’apanage des constructions gigantesques (Tours et barrages), de l’exploitation des centrales nucléaires et Laboratoires de haute sécurité classés P4,  des avions très gros porteurs (800 passagers) ou de la prévention du terrorisme …

*Forge logicielle : système de gestion de développement collaboratif de logiciel. L’objectif d’une forge est de permettre à plusieurs développeurs de participer ensemble au développement d’un ou plusieurs logiciels, le plus souvent à travers le réseau Internet (source Wikipédia)

MS Quotidien
Partenaire de DantotsuPM

j’ai appris à me servir des assomptions, et vous ?

Le par mopertodans best practices, experience sharing3 commentaires

Assumptions de Philip R. Diab

Beaucoup de ce que nous faisons au travail et dans notre vie privée est basé sur des assomptions. Les assomptions sont définies par le Guide de PMBOK comme:  “factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration.”

“Des facteurs que, dans notre planification, nous considérons comme étant vrais, réels, ou certains sans preuve ni évidence.”

assomptionAutrement dit les assomptions sont en fait des croyances que nous tenons pour être vraies, mais sommes incapables de prouver. Le défi que nous rencontrons sur les projets n’est pas la définition des assomptions, mais plutôt de les ignorer. Nous comprenons intuitivement ce que sont les assomptions mais, quand on en vient à la planification, souvent nous ne comprenons pas comment les appliquer.

Dans mes ateliers de formation je dis aux participants si nous savons qu’une chose est en réalité fausse nous ne pouvons pas simplement construire l’assomption qu’elle est vraie. De même, si nous voulons atteindre un certain objectif ou « espérons » avoir le support d’une certaine partie prenante nous ne pouvons pas simplement supposer que le support se matérialisera.

Une de mes pauvres assomptions préférées émises par des équipes de projet ressemble à ceci :

“Nous assumons que le management supportera le projet”

ou

“Nous assumons que le projet a le support exécutif”

Celles-ci ne sont pas efficaces en matière d’assomption parce qu’il ‘est impératif pour le chef de projet et l’équipe de découvrir s’ils ont le support du management ou s’ils doivent aller construire ce support. Créer un plan et exécuter un projet dans l’espoir que le management le supportera est une bonne recette pour un désastre.

Laissez-moi illustrer ce que j’entends par cette citation très puissante par Miguel Angel Ruiz qui s’applique aux assomptions sur les projets :

“Ne faites pas d’Assomptions. Trouvez le courage de poser des questions et exprimez ce que vous voulez vraiment. Communiquez avec les autres aussi clairement que vous le pouvez pour éviter malentendu, tristesse et drame. Avec cette simple attitude, vous pouvez complètement transformer votre vie.”

avis personnel sur les assomptions dans les projetsLe point ici est que nous ne voulons pas confondre le rôle de planification avec celui de fabrication de suppositions parce que nous aurions la flemme d’aller au fond des questions difficiles qui sont des données d’entrée pour notre plan.

Un autre point important à garder aussi à l’esprit consiste en ce que s’il y a des problèmes  ou des décisions que nous savons être vrais, nous ne pouvons en assumer autrement. Par exemple, si nous savons que l’organisation a défini un budget de 500K pour un projet nous ne pouvons pas assumer que le budget du projet augmentera quand débutera l’exécution.

Nous ne voulons pas non plus confondre assomptions et contraintes. Les contraintes sont les facteurs qui sont liés à la portée, au coût et aux délais du projet. En tant que tels, ils diffèrent beaucoup des assomptions. Les assomptions sont d’autre part une source majeure de risque sur le projet. Puisque nous ne pouvons pas prouver par les faits  qu’un point existe, alors il y a un risque que notre croyance soit incorrecte.

Un des éléments les plus importants pour traiter les assomptions est d’admettre que le chef de projet doit continuellement évaluer si des conditions de projet ont abouti à la réalisation de ces assomptions ou les ont rendues obsolètes. Pendant le cycle de vie du projet il y aura les événements qui prouveront que des assomptions étaient fausses ou qui renforceront notre croyance. Quand ces événements ont lieu une évaluation doit être conduite pour déterminer l’impact sur le projet.

Comme je l’ai dit le concept d’assomption signifie quelque chose sur le papier, mais il est probablement beaucoup plus complexe dans la pratique. C’est là où l’expérience et les leçons apprises deviennent inestimables pour améliorer la performance de l’équipe de projet et les chances de succès.

CSP Formation
Partenaire de DantotsuPM

mise en place d’une méthodologie de gestion des risques : félicitations au PMI France-Sud pour le lancement du Pôle Pays de Savoie

Le par mopertodans Non classéLaisser un commentaire

La soirée conférence du 16 février organisée conjointement par l’IUT d’Annecy et le PMI a été l’occasion de présenter les Nouvelles des activités du Pôle Pays de Savoie (Auteur du compte rendu utilisé pour cet article: Frédéric Fiedler – PMP®)

Tout récemment créé (le 19 Octobre 2010) le Pôle Pays de Savoie organisait le 16 Février 2011 son premier événement – avec pour objet une conférence sur la mise en place d’une méthodologie de gestion des risques.

Bruno Laude et le Comité de Pilotage du PMI Pôle des Pays de Savoie : Pascal Gil, Marc Burlereaux, Christine Rieu, Frédéric Fiedler et David Augy.

La présentation de Mr David Augy, Responsable Programme SITA sur la mise en place d’une méthodologie de gestion des risques fut fort appréciée des 150 participants.

David Augy

Mettre en place une méthodologie en anticipant les trois risques majeurs que tout changement peut susciter :

  • Je n’ai pas besoin de ce que l’on m’apporte ….
  • Je suis différent : cela ne s’applique pas à mon métier ….
  • Je n’ai pas le temps …

Mr Augy a donc décrit le déploiement de la méthodologie de gestion des risques en trois phases (1: définition; 2: formation; 3: mise en place et support) avec une démarche permettant à chaque étape de contrer les arguments ci-dessus.

Le projet était ambitieux du fait de la nature du contexte. SITA offre des services informatiques et télécommunications aux compagnies aériennes et aux aéroports tels que : Gestion et optimisation de flotte, services de réservation,  logistique opérationnelle aux aéroports et services de communication en vol.  SITA est présente  dans 220 Pays (70 langues pour 140 nationalités) et la gestion de projet implique directement 300 des 4500 employés de l’entreprise. Le transport aérien est soumis à de nombreuses menaces telles que la volatilité des cours du fuel, la situation économique mondiale, la variation du trafic, le contexte politique,  pression des compagnies lowcost… parfois les volcans en rajoutent !

Un des défis principaux posé au PMO en charge de ce déploiement fut de changer les mentalités et de créer l’envie chez les utilisateurs de mettre en œuvre la gestion des risques. Pour cela une méthodologie dérivée des principes du PMBOK a été explicitée en l’adaptant aux contraintes opérationnelles de SITA. Par une approche légère et pragmatique l’intérêt a été suscité. L’accent a été mis sur la pratique et le travail en groupe et la validité de la méthode pour SITA testée sur un projet pilote.

Le concours et l’appui du management étaient présents, les managers en formation avec leurs équipes, et pour économiser l’emploi du temps des participants des sessions e-learning précédaient la  formation pratique.

Enfin les activités de gestion des risques ont été intégrées de manière obligatoire dans les processus d’établissement de business plan, dans le cycle de formation des chefs de projet et dans le chiffrage des activités. La prise de conscience de la nécessité de gérer les risques a dépassé le cadre purement opérationnel – pour devenir un argument marketing puissant utilisé par les équipes de vente vis-à-vis des clients finaux. Les formations ont été rendues le plus ludiques possible et enfin les équipes projet ont été accompagnées dans leurs premières expériences de mise en œuvre de la méthodologie. Des tableaux de bord ont été mis en place en lien avec les outils de suivi des risques pour représenter dans les indicateurs projet la qualité de suivi de la gestion des risques ce qui a eu pour effet de convaincre les quelques récalcitrants.

Bien que les  effets directs de la mise en place de la stratégie de gestion des risques n’aient pu être « mesurés » spécifiquement  une enquête auprès des chefs de projet a démontré une évolution très claire vers une perception du fait que les risques sont dorénavant mieux gérés à SITA.

En conclusion les participants ont pu bénéficier de quelques conseils sur la gestion du risque :

  • Anticiper
  • Donner la priorité aux menaces à plus fort impact
  • Désigner des ressources pour traiter  les risques suivis
  • Utiliser toutes les stratégies de réponse au risque
  • Prendre en compte dans le budget le coût de la stratégie de « mitigation »
  • Se battre pour des réserves budgétaires adaptées
  • Communiquer de manière régulière et transparente
  • Ne pas oublier les opportunités.

La présentation de Mr Augy comprenait de l’interactivité (quizz avec le public)  et quelques anecdotes vécues ce qui a maintenu l’attention soutenue de l’auditoire jusqu’au bout.

Lors de la conclusion les représentants présents de la Branche PMI Rhône Alpes et le comité de pilotage du Pôle Pays de Savoie ont été présentés au public.

Dominique Garret remet un lot à Antoine Barthélémy, heureux tiré au sort, sous les yeux de Frédéric Fiedler et Stéphane Derouin de PMGS, un de nos partenaires national, qui a en sus offert une formation à un autre participant.

Les échanges autour d’un buffet de qualité offert par l’AFPA  et préparé / servi par ses élèves cuisiniers ont permis de mesurer la satisfaction globale des participants.   Les participants étaient issus de métiers divers, pas forcément familiarisés avec la gestion de projet, et des entreprises et administrations Suisses ainsi que la SMP (association Suisse de Management de Projet) étaient représentés.

Une réussite à reproduire le 18 Octobre prochain à Chambéry pour la conférence réalisée conjointement avec l’ESC  Chambéry   « De la Gestion de crise au management des hommes ».

PMGS Formations en management de projet
Partenaire de DantotsuPM

comment éviter le facteur « Titanic » sur vos projets ?

Le par mopertodans best practices3 commentaires

How to Avoid the Titanic Factor in Your Project, un papier blanc très intéressant de PMI.

En sus de l’histoire contée sur le Titanic et la management des risques sur ce paquebot, j’ai bien apprécié l’idée centrale présentée par l’auteur J. Bruce Weeks: L’analyse des interactions entre plusieurs risques.

En effet, le plus souvent, selon ma propre expérience, même les meilleurs des chefs de projet et leurs équipes identifient, qualifient, quantifient les risques et prévoient des plans de management de ceux-ci en considérant chaque risque de manière isolée. Or, il peut y avoir des interactions importantes entre deux ou trois risques ou davantage, qui vont démultiplier les probabilités d’occurrence d’un risque donné ou bien son impact estimé sur le projet.

L’idée proposée est de regarder pour chaque risque si sa combinaison avec la matérialisation d’un autre risque (ou de plusieurs autres) amplifierait significativement son impact. L’auteur propose d’identifier doubles ou triples interactions dans une matrice permettant de visualiser leur impact combiné sur le projet. Alors, nous pourrons envisager des stratégies ou plans de management de ces risques pour éviter qu’ils ne se manifestent conjointement pour produire un effet catastrophique sur le projet.

Pour identifier les corrélations les plus importantes entre risques, l’auteur présente également un exemple de matrice croisée des risques pour déterminer quelles combinatoires sont les plus probables et réduire ainsi le champ de nos investigations plus détaillées.

à lire « solution pour… Optimiser les risques de l’entreprise »

Le par mopertodans pointeurs utiles1 commentaire

parution ouvrage « solution pour… Optimiser les risques de l’entreprise »

Vincent Iacolare, le co-auteur de ce bouquin est un collègue et ami de PMI France-Sud. Après « pratiquer l’audit à valeur ajoutée« , et « développer l’entreprise numérique« , ce troisième ouvrage permet à Vincent Iacolare (Synertal) et Christophe Burin (EIP Network) d’apporter des réponses pratiques, innovantes, sans tabou ni parti-pris.

Les risques sont partout dans l’entreprise. Aujourd’hui, plus qu’un simple outil, la maîtrise de risque devient un accélérateur de développement et une garantie de pérennité ! Ce livre a pour objectif de vous permettre de reconnaître, mesurer et maîtriser le risque au sein de votre entreprise avec une approche globale et systémique du risque pour en finir avec le mode  » silo « .

Pour en savoir plus: ISBN : 978-2-12-465277-8; boutique Afnor (ref: 3465277)

Tirer parti des Tâches Inactives dans MS Project 2010

Le par mopertodans outils et méthodes2 commentaires

Article original: Leveraging Inactive Tasks in Project 2010


utiliser les taches inactives dans MS ProjectL’une des nouvelles fonctionnalités de Microsoft Project 2010 est de pouvoir inclure des Tâches Inactives dans un planning. Des Ressources Inactives (nous en connaissons tous quelques unes) sont disponibles depuis quelque temps quand on utilise MS Project avec Project Server.

Vous pouvez vous demander pourquoi faire cas de ces Tâches Inactives. Il va probablement y avoir beaucoup d’utilisations ingénieuses de celles-ci qui seront inventées par des utilisateurs comme ils se familiarisent avec la dernière version de Microsoft Project. La ligne officielle assez vague de Microsoft en annonçant cette fonctionnalité était qu’elle permet une planification simplifiée et de jouer des scénarios d’analyse.

Voici deux scénarios où des Tâches Inactives pourraient apporter un avantage significatif.

Changement de contenu :

changement planningUne chose dont vous pouvez être assuré de dans un projet est que les choses changeront et qu’elles changeront à nouveau. Combien de fois avez-vous dû supprimer et rétablir ensuite des tâches en raison de changements introduits puis enlevés ? Avec des tâches inactives vous pouvez simplement marquer une tâche comme étant inactive si elle devait être supprimée du contenu de votre projet. Un enregistrement de celle-ci est conservé dans le planning mais il n’a aucun impact sur les délais, le travail ou les coûts dans le plan de projet. Si la tâche est rétablie, elle est simplement marquée comme étant active à nouveau.

Cette approche élimine le besoin pour le chef de projet de maintenir des versions différentes du planning. Un autre aspect utile de cette fonctionnalité est que vous pouvez voir facilement combien de tâches sont identifiées comme étant inactives sur le cycle de vie d’un projet, ce qui peut être une puissante illustration des effets perturbateurs de changements incessants.

Gestion des risques :

risk managementLes projets ont invariablement des risques associés; Project Server fournit un moyen utile pour suivre les risques associés aux projets dans un espace de travail SharePoint. Dans l’Analyse de Risque, nous identifions des risques potentiels et planifions en conséquence. Notre liste de risques dans SharePoint peut identifier l’impact du risque, notre stratégie de réduction et de contingence.

Des tâches inactives peuvent être incluses dans le planning du projet pour modéliser les actions de réduction qui peuvent être exigées si un risque devait se manifester. Dans le management des risques les mots qui l’indiquent sont “cela ne devrait pas se produire, mais cela arrive …” des tâches inactives peuvent être employées pour permettre la réduction du risque et peut-être encore plus important pour rappeler aux personnes ce risque potentiel et les actions proposées et acceptées pour atténuer le risque. Si un risque se produit, activer les actions dans planning revient simplement à activer la tâche inactive appropriée.

Il n’y a aucun doute que les utilisateurs expérimentés de Microsoft Project inventeront des utilisations encore plus imaginatives de cette nouvelle fonctionnalité de Microsoft Project, faites-les nous connaître. Nous vous ferons bien sûr également part de ce que nous inventerons.

le site de microsoft projet en français
Partenaire de DantotsuPM

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

Le par mopertodans best practices, forum de discussion3 commentaires

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

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

L’arbitraire…

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

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

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

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

Estimations approximatives

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

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

Implication de l’équipe et du chef de projet

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

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

Plans réalistes et atteignables

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

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

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

Implication du client

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

Ressources

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