articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Dans son plan de management des risques, le PM essaie d’anticiper les risques et opportunités, et c’est au jour le jour qu’il le met en œuvre et l’enrichit pour utiliser au mieux toutes les conditions et paramètres.
Allison Izard et Rémy Feller membres du PMI France Côte d’Azur et étudiants à la Skema Business School (Master of Sciences in Business Consulting & Information System Management) réalisent dans le cadre de leurs études un mémoire ayant pour sujet la gestion des risques dans les projets IT.
A cette occasion, ils nous soumettent un questionnaire qu’ils vont utiliser comme source de données pour la rédaction de leur mémoire.
Pour participer, cliquez sur ce lien >> QUESTIONNAIRE « RISQUES dans les Projets IT »
Si vous le pouvez, merci de consacrer 5′ de votre temps pour aider ces étudiants qui s’engagent à partager avec vous, les résultats de leur analyse.
http://sethgodin.typepad.com/seths_blog/2017/04/like-riding-a-bike.html par Seth Godin
Les gens parlent de faire de la bicyclette quand ils veulent nous rappeler que certaines choses, une fois apprises, ne s’oublient pas.
Ce qu’ils ne mentionnent pas est comment nous avons appris. Personne n’apprend à faire du vélo dans un livre, ni même une vidéo.
Vous apprenez en le faisant.
En réalité, en ne le faisant pas. Vous apprenez en le faisant mal, en tombant, en remontant dessus, en le faisant à nouveau.
PS : Cette approche marche pour des tas de choses, pas seulement le vélo. La plupart des choses, en fait.
https://www.pmi.org/learning/publications/pm-network
#1 Soucis Économiques72% de cadres positionnent les conditions économiques internationales et domestiques comme un risque significatif, en faisant le souci principal en 2017.
66% de cadres ont évalués les changements dans les régulations comme ayant un impact significatif sur leurs organisations. Pour les projets à long terme qui doivent respecter des règlementations spécifiques, ces changements peuvent directement impacter les coûts et la viabilité de leurs projets.
#3 Cyber sécuritéLes soucis de cyberattaques sont parmi les cinq premiers risques pour les tailles de toutes sociétés consultées. C’est particulièrement vrai pour les chefs de projets informatiques qui doivent équilibrer innovation et simplicité d’utilisation avec le besoin de protéger les données de brèches de sécurité.
Le rythme très rapide d’innovation est un souci grandissant : 2017 est la première année que ce risque se classe parmi les cinq premiers. C’est particulièrement exigeant pour les équipes de projet qui basent leur retour sur investissement sur être les premiers à commercialiser une nouvelle innovation.
Une accélération des infractions de vol de données a mis la vie privée et le vol d’identité en cinquième plus haut risque pour la seconde année de suite.
Une étude de Protiviti and North Carolina State University’s Poole College of Management
Pour un aperçu du contenu de la dernière édition de PM Network
PMI is a registered mark of Project Management Institute, Inc.
« Nous posons, en outre, que l’assomption du risque n’est pas une activité productive par elle-même; c’est le risque surmonté, éliminé, qui permet un accroissement des valeurs ajoutées dans la firme et du produit réel dans l’économie nationale. » Perroux
http://leadingstrategicinitiatives.wordpress.com/2012/04/26/how-to-identify-strategic-assumptions/
L’un des outils les plus importants pour transformer une vision en résultats est de manager les assomptions stratégiques. Les techniques décrites ci-dessous sont faciles à suivre, elles ajoutent de la valeur et peuvent vous aider à lancer votre initiative stratégique.
Les assomptions sont des outils pour la planification et la définition de base de l’assomption (dans le contexte de la planification) est :
Les assomptions sont ces facteurs que l’on considère vrais, réels ou certains dans l’objectif de créer une compréhension partagée du plan.
Nous DEVONS faire des suppositions quand nous planifions, en utilisant notre meilleur jugement et les données disponibles. Sinon, ce que nous appelons « le plan » est seulement un désir irrationnel et incohérent.
De plus, nous ne pouvons pas rester dans un mode étude : nous devons accepter le risque que nos hypothèses pourraient être fausses.
Heureusement, si nous suivons deux règles de bon sens nous pouvons éviter les erreurs majeures : 1-documentez toujours les assomptions et 2- validez-les toujours pendant l’exécution.
Des assomptions stratégiques sont les facteurs critiques qui si invalides, causeraient la mort ou des changements significatifs à l’initiative. Par contraste, comparez-les aux hypothèses utilisées dans les estimations qui sont les facteurs à la base de suppositions de coût, de durée, ou de niveau de ressources.
Voici quatre exemples de suppositions stratégiques :C’est que, si elles sont invalides, il y aura de bonnes raisons d’annuler l’initiative ou de la rediriger de façon majeure.
Il s’avère que vous trouverez les suppositions stratégiques dans 4 domaines :
J’étais le conseiller d’un dirigeant qui avait personnellement des doutes sur la capacité de l’équipe de mise en œuvre à penser stratégiquement. Il soupçonnait que les réalisateurs avaient un travers « grand système technique » qui les amènerait à la conception d’une solution qui serait inadéquate pour répondre au besoin.
Pendant une « réunion stratégique de préparation à la mise en œuvre » qui impliquait l’équipe et lui-même, nous avons demandé à l’équipe de préparer des questions pour le dirigeant. Ils ont totalement échoué à penser stratégiquement et se sont reposés sur des assomptions usuelles. En fait, ils faisaient plusieurs hypothèses erronées:
Ce dirigeant a engagé l’équipe à penser plus stratégiquement. J’ai aussi vu des situations où l’équipe est devenue la cible des critiques en raison de leurs mauvaises assomptions.
Les personnels techniques ont été formés pour trouver et appliquer « les bonnes formules ». Cette formation et cet état d’esprit fonctionnent bien dans des domaines qui sont bien délimités. Elle ne marche pas aussi efficacement dans des domaines stratégiques.
Ils font l’erreur de faire des assomptions plutôt que de poser des questions.
Souvent ces hypothèses de travail sont invalides et amènent à de mauvaises solutions et causent des gaspillages de ressources.
Le leader d’une initiative stratégique doit assumer le rôle de responsable de la formation. Cela signifie être curieux, se méfier des erreurs et poser davantage et de meilleures questions.
http://www.ims-web.com/blog/5-ways-to-stay-proactive-during-project-delays par Jeff Collins
Des retards de projet surviennent en conséquence de la piètre planification, de communication inadéquate, de réduction des ressources allouées et de changements dans le contenu du projet. En outre, les retards de projet appauvrissent le moral des collaborateurs et réduisent la vitalité de votre équipe de management de projet.
Heureusement, vous pouvez réduire les effets négatifs des retards de projet par cinq actions clés. Lisez ce qui suit pour voir comment votre équipe de management de projet peut maintenir un environnement positif et rester productive quand des retards de projet arrivent.
Les membres de l’équipe et des ressources qualifiées peuvent ignorer des retards actuels du projet. Donc, entretenez un bon niveau de communication avec les membres de l’équipe et personnes qualifiées est critique pour garantir que des retards dans le projet n’aboutissent pas à l’échec du projet. Tenez des réunions quotidiennes avec tous les contributeurs et membres de l’équipe pendant la durée de ces retards de projet. Sollicitez des retours d’information et options possibles ou façons de réduire les effets négatifs du retard de leur part. En restant connectés, vous pouvez maintenir une relation positive avec toutes les parties affectées.
Les retards peuvent être un indicateur de problèmes à venir sur votre projet. Quand les retards surviennent, réévaluez l’état actuel de votre projet. Comment ce retard initial impactera-t-il d’autres tâches et activités ? Est-ce que ce retard est raisonnable, ou est-il simplement un moyen de réduire le coût de votre projet ? Ces questions identifieront pourquoi le retard est là et comment des retards semblables pourraient être minimisés dans l’avenir.
Si le retard est localisé sur des tâches et activités spécifiques, vous pouvez pouvoir déplacer des travailleurs et des allocations de ressources vers des tâches non-affectées. Bien que ceci change le planning des activités, il permet à votre personnel de rester productif quand votre projet souffre de retards. En outre, vous devez considérer comment les retards affecteront le périmètre global de votre projet.
Parfois, les retards peuvent être le résultat de votre équipe projet et l’incapacité des personnes à réaliser dans des délais peu réalistes. Si les retards semblent arriver sans avis du management exécutif, passez en revue les données et facteurs dans votre analyse de risques. Conduisez une session supplémentaire d’analyse de management des risques pour définir pourquoi et comment les problèmes sont survenus. Si le problème réside avec un membre spécifique de l’équipe, envisagez de fournir une formation supplémentaire pour corriger le problème.
Certains retards de projet peuvent saper la capacité de votre équipe à compléter un projet dans un délai donné. Cependant, des retards ne peuvent être évités et votre équipe doit rester productive pendant tout le projet. Demandez aux membres de l’équipe et contributeurs de conduire des inspections de la qualité du travail réalisé et rechercher des erreurs. Bien que cette étape soit normalement la dernière partie d’un projet, vous pouvez réduire l’impact global des retards en conduisant des inspections de qualité en continu.
Quand vous ignorez la possibilité de retards de projet, vous allez plus probablement exposer de faibles qualités de leadership et refuser de vous adapter quand les retards arrivent. En prenant ces cinq actions, votre équipe de management peut rester productive pendant ces périodes de retards de projet.
Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser les choses les plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager un montant faible et raisonnable de dette technique peut en réalité faire avancer le projet plus rapidement et permettre d’atteindre l’objectif d’avoir un logiciel utilisable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la dette technique : « Comme toute dette dans la vie de tous les jours, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
Derek remarque aussi que tout comme toute dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre : Elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement l’équipe de support technique ou quelqu’un d’autre en aval.
Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui jetterait les dés pour décider de votre taux d’intérêt. Alors, si vous n’êtes pas obligés de prendre ce risque, ne le prenez pas.
Mais la dette technique est-elle vraiment une proposition de type tout ou rien, blanc ou noir ?
Quand elle considère la Dette Technique, une société doit déterminer combien devrait être investit pour y remédier. La meilleure façon de le faire est en donnant une valeur monétaire à la dette technique pour allouer une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques à rembourser cette dette par rapport aux pertes potentielles coté business en raison d’un échec qui n’était pas envisageable avant de contracter cette dette.
Le but de monétiser la dette technique est de limiter le nombre de violations de la qualité structurelle, ou ce qui est plus important, le coût de les réparer, bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.
Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure de calcul de la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont généré la dette technique.
La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite de devoir payer plein d’intérêts.
Alors, profitez de cette période un peu plus calme pour entamer ces travaux de remboursement…
Beaucoup d’organisations finissent par institutionnaliser la prudence, au point de ne plus être assez réactives face aux changements rapides de l’environnement et de perdre l’aptitude à saisir les opportunités. Multiplier les analyses, pousser les validations systématiques, ne plus arriver à prendre de décision – sont autant d’exemples d’une précaution accrue favorisée par un environnement qui sanctionne trop souvent l’échec.
Ce comportement est toujours inefficace, car nous finissons par nous protéger des choses qui ne sont pas susceptibles de se produire, et nous surestimons le montant de la protection dont nous avons besoin.
Un des nouveaux enjeux de performance est donc de redonner aux équipes l’esprit d’initiative et le courage de prendre des risquesLa célèbre devise de la British SAS (Special Air Service) «qui ose gagne » appliquée aux organisations et aux projets, pourrait les pousser dans la bonne direction. Mais, comme l’indique Jean-Claude Killy, « pour gagner, il faut risquer de perdre ». Ainsi, audace et précaution sont donc nécessaires pour favoriser la prise de risque intelligente.
Adopter l’attitude « qui ose gagne » encourage l’identification des opportunités. Pour promouvoir cette démarche, nous pouvons aborder l’analyse des risques selon plusieurs angles:
Demander aux équipes de voir le business ou l’investissement d’un projet comme leur compte bancaire. Chaque menace s’inscrirait au débit –une charge supplémentaire – et chaque opportunité possible au crédit –un revenu additionnel. La plupart des personnes comprennent alors que, pour maintenir ou maximiser leur compte en banque, il est plus efficace de se concentrer sur l’augmentation des gains que de mettre tous les efforts sur la réduction des charges!
Revoir la liste des menaces et pour chacune d’elles valider s’il existe une opportunité associée selon la grille de lecture suivante:
| Grâce à | [menace] | un [évènement positif] pourrait se produire | Qui apporterait la valeur suivante |
Le but est de trouver la ou les opportunités qui comptent afin de placer les efforts sur les bonnes priorités.
Obliger les équipes à commencer l’identification des risques par les opportunités. Empêcher les de penser aux menaces tant qu’une ou plusieurs opportunités qui comptent n’ont pas été inscrites dans le registre des risques.
Quelle que soit le point de vue choisi, un changement de méthode permettra aux équipes de changer de manière de penser et de commencer à oser.
Encourager les individus à prendre des risques soulève la question de savoir jusqu’où on peut aller dans la prise de risque. Des limites doivent être clairement définies et partagées. Elles s’appuieront sur la création et la protection de valeur attendue par l’organisation et ses parties prenantes. Une limite est le point à partir duquel « le jeu n’en vaut plus la chandelle ».
Dans le cas des opportunités, une limite est atteinte lorsque l’impact positif attendu n’est pas suffisant par rapport à la menace potentielle si l’opportunité ne se réalise pas ou n’a pas l’effet escompté. Ces seuils d’audace doivent être définis lors du démarrage des projets, portés par le management, revus régulièrement, communiqués et partagés avec les équipes.
En intégrant ces seuils, le processus de management du risque favorise l’élaboration des plans de réponse efficaces. Ainsi pour chaque opportunité qui compte, l’équipe devra estimer le « risque de perdre » afin de valider que la prise de risque reste dans les limites acceptables.
| Analyse de l’opportunité | Menace associée à l’opportunité | ||||
| Opportunité | Résultats positifs attendus | Plan d’action pour la réaliser |
Risque de perdre | Résultats négatifs attendus | Limites acceptables |
Dans le principe « qui ose gagne », lorsque l’on ose c’est pour gagner non pour espérer ne pas perdre !
Cette attitude de combat positive nous aide à engager des ressources pour le développement et la mise en œuvre de réponses efficaces. L’importance de prendre des risques mesurés permet l’attitude proactive de chacun.
Les équipes proactives maîtrisent les situations et font bouger les choses plutôt que de simplement s’adapter à la situation ou attendre que quelque chose se produise.
Être proactif c’est donc aller de l’avant : oser !
Ainsi, au-delà des processus, la prise de risque est souvent un changement de paradigme. Cette culture de l’audace raisonnée doit être stimulée au plus haut niveau des organisations pour supprimer la peur de perdre et permettre aux équipes d’oser pour gagner.
http://themanagersdiary.com/90-of-the-things-you-worry-about-wont-happen/ par Cameron
« Si vous écoutez vos craintes, vous mourrez sans jamais savoir quels super personne vous auriez pu être. » Robert H. Schuller
C’est stressant et typiquement improductif. Une des grandes leçons que j’ai apprises au fil des années est que c’est aussi un gâchis de temps. Cela gaspille du temps parce que la plupart de ce qui nous inquiète finit tout simplement par ne pas arriver. Tout ce temps passé à réfléchir à ce que vous feriez est perdu parce qu’il était en premier lieu peu probable que cela se produise. Laissez-moi maintenant faire une distinction rapide. Je ne parle pas de s’inquiéter de bien remplir les fonctions vitales de votre travail, car c’est votre job. Je parle de toutes les petites pensées négatives et incessantes qui traversent votre cerveau quand vous avez apparemment un espace cérébral disponible. Ce sont ces choses qui « pourraient » arriver qui ajoutent seulement des soucis à votre journée. Mais si vous y repensez, combien d’entre elles ont surgi ? Pas beaucoup.
Une chose qui peut se produire est que si vous ne gardez pas votre cerveau focalisé sur des tâches constructives, il commence à créer des choses pour s’occuper. Une des choses les plus juteuses sur lesquelles il peut passer son temps libre est d’inventer des choses apparemment constructives et voir de combien « et si » possibles il pourrait devoir se préoccuper. Et même s’il y a d’habitude un petit filtre sur cela en fonction de la probabilité qu’un événement se produise, ce n’est pas toujours le cas.
Oui, la réduction de risque est l’une de ces choses, mais il y a des limites à cela. Si vous laissez vos pensées vous contrôler, vous commencerez à penser à des choses de moins en moins probables qui pourraient arriver. Même si j’aurais pu intituler ce billet « Ne vous inquiétez pas! », il vaut mieux que vous l’attaquiez à la racine en vous recentrant sur des choses constructives avant que « la spirale des soucis » ne prenne le dessus.
« Une des plus grandes découvertes que fait un homme, une de ses surprises les plus fortes, est de constater qu’il peut faire ce qu’il craignait de ne pouvoir faire. » Henry Ford
http://projectriskcoach.com/2016/04/22/how-to-identify-and-manage-secondary-risks/ par Harry Hall
Une réponse à un risque peut créer d’autres risques. Ceux-ci sont des risques secondaires qui peuvent s’avérer plus significatifs que les risques primaires si nous n’y prenons garde.
L’une des épisodes du dessin animé de la Panthère Rose la montrait aux prises avec une souris dans sa maison. La souris la rendait folle; elle devait trouver une façon d’éliminer ce problème.
La Panthère Rose, portant un costume de chat, a chassé la souris de la maison puis dans la rue. Les chiens du voisinage ont poursuivi « le chat ». La Panthère Rose a couru pour sa survie, mais a fini déchirée en lambeaux.
Un risque secondaire est un risque qui est créé par une réponse à un autre risque.
Le propriétaire de risque peut être fort bien intentionné dans sa réduction de la probabilité et de l’impact d’un risque; cependant, beaucoup de réponses ont le potentiel de créer des risques secondaires. Si le propriétaire de risque atténue une menace, en exécutant un plan de contingence, ou en exécutant un plan de repli, il peut causer des risques secondaires.
En définissant des plans de réponse aux risques, leurs propriétaires devraient identifier, capturer et développer des plans de réponse aux risques secondaires dans le registre des risques. Les propriétaires de risque devraient chercher les réponses au risque les plus efficaces et qui produisent la moindre quantité de risques secondaires.
Imaginez que vous faites partie de l’équipe projet qui a été chargée d’ajouter une nouvelle fonctionnalité à un logiciel de gestion des comptes clients sous quatre mois. Le projet est critique pour pouvoir espérer battre la concurrence en lançant rapidement la commercialisation et en capturant au passage des parts de marché.
En identifiant les risques, l’équipe projet n’est pas certaine que les deux développeurs assignés pourront compléter les tâches de programmation dans les temps.
L’équipe décide que, si les développeurs prennent une semaine ou plus de retard sur l’échéancier, ils ajouteront une autre ressource. Cependant, l’équipe reste inquiète car cette réponse peut causer un risque secondaire : l’ajout d’un nouveau développeur exigera que les développeurs originaux lui fournissent des explications et de l’orientation, les mettant encore plus en retard dans leurs tâches. L’équipe capture alors ce risque secondaire dans le registre des risques et développe des plans de réponse à cette éventualité.
Passez en revue les plans de réponses de risque que vous avez développés et identifiez les risques secondaires. Évaluez ces risques secondaires et développez des plans de réponse pour les plus significatifs.
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.
Regardez les travaux du psychiatre Aaron Beck et des psychologues Amos Tversky et Daniel Kahneman sur le rôle des « biais cognitifs »
IRM’s Risk Appetite and Risk Tolerance Guide – Risk appetite is a core consideration in an enterprise risk management approach. Risk appetite can be defined as ‘the amount and type of risk that an organisation is willing to take in order to meet their strategic objectives.’
This document from the Institute of Risk Management is a useful tool and source of information. For free access to the Executive Summary, click here.
ISO 31000 – Risk Management – from International Organization for Standardization. This standard is intended to help organizations to manage risks effectively. Several ISO risk management guides are also available.
For more go to: http://www.iso.org/iso/home/standards/iso31000.htm
Also, read: use the RARA model to remove your confusion between Risk Appetite and Risk Attitude
Pour améliorer en continu la performance des projets, les organisations s’orientent vers :
Toutes ces solutions structurent le management de projet, produisent de l’information en continu mais aucune d’elles ne peut prédire dynamiquement le taux de dérive d’un projet et proposer rapidement les corrections appropriées pour le remettre sur les rails.
Le « machine learning » ou « apprentissage automatique » en français permet de développer des modèles informatiques intelligents et adaptatifs (en auto-apprentissage), exploitant un nombre important de données. Ce sont des modèles prédictifs qui cherchent des corrélations significatives de données historiques et transactionnelles afin d’identifier risques et opportunités.
Les applications du «machine learning » sont surtout connues chez les entreprises du web, notamment intégrées dans les systèmes de recommandation des sites marchands ou des jeux en ligne, le filtrage anti-spam, l’optimisation des stocks, la segmentation et le ciblage des clients. Mais de nouvelles applications commencent à apparaitre dans le monde industriel.
Selon certains journaux spécialisés, le machine learning va être une source de gain énorme pour les entreprises qui pourront multiplier leur performance marketing par 10, la qualité de leur maintenance par 8 et réduire leurs risques financiers par 5, d’ici 2030.
Dans ce courant, nous avons développé un cadre pour intégrer le « machine learning » dans des modèles prédictifs permettant d’anticiper, éviter et/ou corriger les dérives des projets.
Notre objectif est d’amener l’organisation à exploiter efficacement toutes les données « projet » dont elle dispose afin de créer des agents «intelligents » qui accompagneront la gouvernance des projets dans les prises de décision nécessaires au succès des projets en cours.
Ce modèle d’analyse prédictive peut être utilisé aux étapes majeures du cycle de vie des projets comme les passages de Gate (débuts ou fins de phases), les revues de pilotage mensuel ou encore les jalons contractuels.
Ces capacités reposent sur une base de données historiques des projets comme représentée ci-dessous :
L’interaction entre le modèle et le chef de projet ou l’instance de gouvernance est permanente ce qui permet des cycles courts et itératifs d’entrées-sorties. A chaque cycle, le modèle s’ajuste et apprend pour restituer de nouvelles informations améliorant la prise de décision.
Notre modèle est basé sur les technologies éprouvées telles que le « support vector machine [SVM], fast messy genetic algorithms [fmGA], matrix factorization », ou encore les réseaux de neurones.
Une solide méthodologie basée sur les principes du « lean management » est intégrée au modèle afin que seules les connaissances pertinentes et utiles soient réintégrées au cœur du système.
La mise au point du processus complet adapté aux besoins de l’organisation se réalise sur 3 à 6 semaines.
Pour bénéficier de cette approche, les organisations doivent disposer au préalable d’un certain niveau de maturité en gestion de projet :
Tous les secteurs industriels sont concernés: sociétés d’engineering, de construction, fournisseurs de solutions logicielles d’entreprise, sociétés de services, industrie de fabrication, R&D, etc..
Il existe un modèle pour chaque environnement, nous sommes à l’écoute de vos besoins !
Lisez un article complet sur cette approche ou contactez Yannick Meriguet – Beagle Consulting : ymeriguet@beagle-net.com
Le point de départ du speaker est qu’un problème est un risque, identifié au préalable ou pas, qui s’est matérialisé. En partant de ce précepte, il devient naturel de manager un problème comme on le ferait d’un risque. En particulier lors de la mise en œuvre du plan de management que nous avons prévu pour ce risque. Il en résulte un registre des problèmes qui ressemble fort à celui des risques avec quelques éléments supplémentaires pour suivre la progression vers la résolution du problème.
Dans un second temps, le speaker propose quelques mesures de suivi de l’ensemble des problèmes que je trouve fort pertinentes.
Je leur ajouterais un suivi du nombre total de problèmes ouverts. En effet, une somme de petits problèmes est aussi indicative de dysfonctionnements sérieux qu’un gros problème. Donc, le contrôle de l’évolution de cette métrique est à mettre en place.
Sur ce même sujet du management des problèmes, Seth Godin a publié (il y a déjà plusieurs années) un billet qui nous rappelle qu’il n’est jamais recommandable d’essayer de cacher un problème voire de refuser de le reconnaître.
Souvent, nous hésitons à identifier un problème par peur de ne pas être capable de le résoudre.Savoir que nous devrons vivre avec quelque chose que nous ne pouvons changer nous donne de bonnes raisons de ne pas le verbaliser. Comme si l’énoncer empirerait la situation.
Même si cette forme de déni pourrait être acceptable pour une personne (notez le conditionnel), c’est une approche totalement inadaptée pour une organisation, grande ou petite. Car il y a très probablement dans l’organisation des ressources capable de résoudre le problème si vous pensez qu’il mérite d’être éliminé.
Mettez vous ainsi que vos équipes sur le chemin de l’identification des problèmes sans regarder si vous serez capables de les résoudre. Listez les, priorisez les, puis allez cherchez l’aide nécessaire à votre organisation pour les attaquer.
Click here to subscribe for free regular briefings on best-practice risk management from The Risk Doctor Partnership.
http://www.pmsouth.com/2013/05/04/how-to-approach-a-fixed-date-project/ par Harry Hall
Beaucoup de chef de projets haïssent les projets aux dates de fin fixées à l’avance. Les managers décident d’une date et disent « respectez-la ». Souvent, le manager a peu ou aucune compréhension du niveau d’effort requis.
Manipulation. Les chefs de projets estiment qu’ils sont manipulés. LE management donne une date empirique. Plus tard, ils changent la date quand elle ne peut pas être respectée. Ce syndrome amène de la méfiance entre PMs et direction.
Quand vous êtes mis au challenge de manager un projet à date fixe, voyez-y une opportunité. Vous pouvez livrer le projet dans les temps avec la bonne approche.
Engagez-vous. Faites savoir à votre sponsor que vous mettrez tout en œuvre pour livrer le projet à la date demandée. Établissez un rapport de travail positif avec votre sponsor. Exprimez le besoin de collaboration entre le sponsor et l’équipe.
(Gardez à l’esprit qu’une bonne gestion des risques raccourcit souvent le projet. Les risques sont éliminés ou diminués. Cependant, il y a toujours les risques résiduels qui devraient être reconnus dans vos fonds de prévoyance. Par exemple, vous pouvez spécifier que le projet exige que des six semaines supplémentaires pour manager les risques identifiés sur le projet.)
Votre approche envers un projet à date fixe déterminera votre succès.Le Chef de projets doit avoir la bonne attitude, s’assurer que les engagements envers le sponsor et l’équipe sont appropriés et choisir les bons processus, outils et techniques.
Mon conseil en matière de réponse sur ce sujet est de faire simple.
Et votre interlocutrice le sait probablement.
Vous pouvez aller un peu plus loin en décrivant à haut niveau ce que vous aimez voir dans un registre des risques : type/catégorie, description, qui l’a remonté, quand, à qui est assigné le risque, son statut, l’approche de réponse au risque (atténuation, évitement, acceptation, transfert), sa probabilité, son impact, son niveau (en général probabilité x impact) et si résolu : date de résolution et solutions apportées.
Un item moins fréquemment mentionné et qui pourrait vous faire remarquer est d’avoir identifié les signaux d’alarme qui indique que le risque est proche de se matérialiser.
Autre petit bonus sur le sujet des 4 étapesExpliquer que votre expérience vous amène à éviter de combiner les sessions d’identification de risque (où tout qui se présente sera noté) avec des sessions de qualification des risques (où l’impact et la probabilité doivent être évalués et des réponses aux risques proposées). Passer trop rapidement à la seconde étape empêche souvent d’explorer tous les risques potentiels.
http://sethgodin.typepad.com/seths_blog/2015/07/shark-attack.htmlPar Seth Godin
Une attaque de requin est soudaine, viscérale et accablante.
Et, il est impossible d’être un dur à cuire face à elle.
La terreur pure nous écrase, nous paralyse, nous rend impuissant à agir à son encontre.
Les attaques de requin sont incroyablement rares.
La même chose est vraie de votre projet, de votre prochaine prise de parole en public et de la prochaine réunion que vous êtes sur le point de planifier.
L’utilisation de l’expression, « attaque de requin » pour décrire un piège imaginaire mais horrible est en fait une bonne façon de nous rappeler de nous concentrer sur autre chose.
Mieux vaut en effet se préparer pour un danger tant probable qu’évitable plutôt qu’une très improbable « attaque de requin ».
I found this recording of Professor Daniel Kahneman very interesting. He explains how a Pre Mortem approach can help to avoid tunnel vision and biases in group decision processes.
By asking upfront, at the very begining of the project before all decisions are taken, some situational questions such as « Assume that we have decided to launch this project. We’re a year ahead from Today, our project has been a total disaster. What did happen? », you’re allowing the pessimistic thinking to express itself openly and might discover some new risks and potential or probable errors.
Once you know these exist, you can do something to prevent or manage them…
Thanks to 12manage – The Executive Fast Track for pointing me to this useful video.
DantotsuPM.com 