 Your new post is loading...
Your new post is loading...
Scoop.it!
Digital Project Handbook Cheat Sheet from NatalieMoore. 
No comment yet.
Sign up to comment
Scoop.it!
Project Management Body of KnowledgeLe Project Management Body of Knowledge (PMBOK) ,est le guide du Project Management Institute définissant les champs de connaissance couvrant la gestion de projet, et recensant les bonnes pratiques professionnelles en la matière. À ce titre, il sert de base de référence, pour établir les contenus de cours sur la gestion de projet et pour l'élaboration d'examens de certification.
Mickael Ruau's insight:
ObjectifsLe principal objectif du Guide PMBOK est de définir le sous-ensemble du Corpus des connaissances en management de projet qui est généralement reconnu de bonne pratique. Cela signifie qu’il présente la notion de manière générale et de façon qu’elle soit applicable au plus grand nombre car elle n’est pas uniforme et chaque manager doit déterminer ce qui est le plus approprié. Il fournit aussi un lexique commun pour le management de projet qui est essentiel pour la profession. Mais ce guide concerne uniquement les projets individuels et les processus de management de projet généralement reconnus de bonne pratique. Le PMBOK est un standard officiel de l'ANSI4, reconnu internationalement (IEEE Std 1490-2003), qui documente les bonnes pratiques et les fondamentaux de la gestion de projet. Il a une portée générale et s'applique aux projets de nombreux secteurs, comme la construction, le logiciel, l'ingénierie et l'industrie, etc. ContenuLe contenu est très proche et complémentaire5 de la norme ISO 21500 qu'il a par ailleurs inspiré.
Scoop.it!
Pour obtenir un consensus
Mickael Ruau's insight:
Pour un consensus rapide : la méthode analytiqueCette résolution de problème peut être bouclée en cinq minutes avec un vrai consensus ; pour peu que l’on utilise la bonne méthode.
S.P.A.S.A. Situation : lever d’abord les ambiguïtés. Il faut savoir perdre un peu de temps pour en gagner beaucoup. Si les informations ne sont pas complètes et les mêmes pour tout le monde, on en arrive à faire des réunions où il est impossible de trouver un accord. Par exemple sur cet exercice, les participants ont la possibilité de demander individuellement des infos, certains le font et les gardent pour eux, les autres acceptent de parler dans le flou des connaissances qu’ils n’ont pas. Ici par exemple : • le compas ne marche pas, le champ magnétique de la lune n’est pas polarisé ; • on est bien sur la surface éclairée ; • la radio marche mais à faible distance (car FM + RELIEF) ; • relief lunaire accidenté (crevasses...) ; • il y a sur les combinaisons spatiales des points • prévus pour les injections (piqûres) ; • les fusées éclairantes sont à combustion interne (elles fonctionnent sur la lune). Poser le problème : une définition commune du problème. Même lorsque l’on a l’impression que le problème est simple, chacun le comprend à sa façon. Il faut toujours se mettre d'accord sur cette définition du problème. Ici, par exemple, il ne s’agit pas de réparer ou d’attendre des secours ou quoi que ce soit d’autre, mais d’effectuer un parcours de 150 km. Analyse du problème : le choix des critères ? L’analyse des problèmes doit s’appuyer sur des critères clairs. Sinon comment analyser un problème si l’on ne sait pas sous quel angle de vue ? Ici les critères sont simples. Il faut : • survivre, • s’orienter, • se déplacer. Liste type du National Aeronautics Space Administration Solution : la hiérarchisation. Par rapport à ces critères, quels sont les objets indispensables, nécessaires, utiles, inutiles. 1. Oxygène 2. Eau Indispensables 3. Carte 4. Nourriture 5. Radis Nécessaires 6. Corde 7. Trousse d’urgence 8. Parachute 9. Canot de sauvetage Utiles 10. Fusées 11. Revolvers 12. Lait 13. Chauffage 14. Compas Inutiles 15. Allumettes Action : on y va !!!
Une méthode analytique efficaceSi l’on pratique avec une telle démarche, on arrive à la solution en un temps record, les petites différences avec la liste-type de la NASA sont minimes et les scores très bons avec un réel consensus.
Scoop.it!
 Projet (management)Un projet est - en management d'entreprise - un ensemble finalisé d'activités et d'actions entreprises par une " équipe projet " sous la responsabilité d'un chef de projet dans le but de répondre à un besoin défini par un contrat dans des délais fixés et dans la limite d'une enveloppe budgétaire allouée.
Mickael Ruau's insight:
Les différentes manières de s'organiserStructure fonctionnellestructure fonctionnelle Chaque spécialiste métier reste dans sa division et communiquera directement avec ses homologues pour faire les choix relatifs au projet. Dans ce cas il n'y a pas de chef commun. L'implication dans le projet ne se fait que si les acteurs s'y attachent et que leur direction métier peut leur laisser suffisamment de temps. Structure de coordination de projetstructure de coordination de projet Le coordinateur n'est qu'un gestionnaire du projet : il ne dirige pas tous les acteurs mais il est en relation étroite avec les chefs de projet métier. Les acteurs sont donc déchargés de la tâche de gestion de projet, qui est en plus effectuée de façon plus efficace puisque centralisée. Mais il n'y a toujours pas de direction du projet qui pourrait « concurrencer » les directions métier. Structure de direction de projetStructure de direction de projet Le directeur de projet gagne en pouvoir puisqu'il a un poids hiérarchique sur les autres participants au projet. Cela lui permettra d'y apporter encore plus de cohérence en donnant des priorités dans la réalisation des différentes tâches du projet plutôt que des conseils qui pouvaient être plus ou moins suivis. Cependant apparaît le problème du conflit de direction puisque les intervenants métiers ont maintenant deux chefs : un pour leur métier et un pour le projet. Leur comportement risque d'être encore plus imprévisible. Structure de projet sortiLa structure de projet sorti Tous les acteurs du projet quittent la structure dans laquelle ils étaient (y compris physiquement : le travail sur le projet se fait souvent en plateau (open-space) pour une meilleure circulation de l'information). La hiérarchie est maintenant claire et l'efficacité grandement améliorée (plusieurs années de développement gagnées pour le développement d'une voiture par exemple). Le problème se pose cependant de la reconversion des différents acteurs à la fin du projet puisqu'ils auront perdu leur compétence métier en ayant passé plusieurs années sur des actions variées. De plus, si l'entreprise n'a pas de projet à proposer directement à la suite, ces acteurs risquent d'être débauchés par des concurrents qui lancent leur projet.
Scoop.it!
Dans son livre Système 1 / Système 2 : Les 2 vitesses de la pensée (Aff), Daniel Kahneman explique comment nous prenons des décisions au quotidien et qu’est-ce qui provoque nos erreurs de jugement. Il distingue 2 façons de penser qui influencent notre prise de décision :
Dans cet article on va voir à quoi correspondent ces 2 vitesses de la pensée et comment les utiliser à notre avantage pour prendre des décisions.
Scoop.it!
Learn this easy trick to manage employees more effectively, as well as help to convey what's really important from the company perspective.
Mickael Ruau's insight:
5 Things ConceptBack then, Joel was already running Fog Creek and StackExchange at the same time, and he came to a point where he needed to quickly understand what was happening in his companies and what people were working on. Conceptually, this turned into the “5 things” idea: he realized what he really wanted to hear from his team was a list of 5 things:
He would then have only 5 items per person to check on. As a manager he sought to gain a clear perspective of what was happening, and he thought a process like this would help his employees prioritize their work and truly accomplish something.
Scoop.it!
Méthode mathématique d'analyse multicritèreLes méthodes mathématiques d'analyse multicritère ont pour but la résolution des problèmes d' Aide à la décision multicritère. Elles constituent une étape importante du processus de décision, qui suit celle d'identification et de définition du problème, et aboutissent au choix d'une ou plusieurs solutions optimale(s), au sens de Pareto, parmi un ensemble discret de solutions, via une procédure de sélection.
Mickael Ruau's insight:
Sommaire
Scoop.it!
Besides Pugh Matrix and Decision matrix, it is also known by the name such as Grid Analysis, Pugh Matrix Analysis, and Multi-Attribute Utility Theory)
Mickael Ruau's insight:
PUGH matrix (Decision Matrix) Procedure
Method 1: Establish a rating scale for each criterion. Some options are:
Method 2, Pugh matrix (Decision Matrix): Establish a baseline, which may be one of the alternatives or the current product or service. For each criterion, rate each other alternative in comparison to the baseline, using scores of worse (–1), same (0), or better (+1). Finer rating scales can be used, such as 2, 1, 0, –1, –2 for a five-point scale or 3, 2, 1, 0, –1, –2, –3 for a seven-point scale. Again, be sure that positive numbers reflect desirable ratings.
Scoop.it!
Proposition d'un modèle enrichi d'explications pour organiser la phase opérationnelle de vos décisions
Scoop.it!
Dans cette partie, nous allons voir exactement comment construire un arbre de décision du début jusqu’à la fin.
Mickael Ruau's insight:
Pour conclure l’arbre de décision est un moyen puissant de prendre des décisions quand on fait face à un gros volume d’informations et que nos choix sont à plusieurs niveaux. Pour l’appliquer il suffit de suivre 6 étapes simple :
Scoop.it!
Quelle est la meilleure approche pour mener un projet ? Un des critères essentiels à prendre en compte est votre équipe projet.
Scoop.it!
Identifiez les avantages et inconvénients des approches agile, prédictive et hybride. Ainsi, vous gagnerez en efficacité et en souplesse dans vos projets.
Mickael Ruau's insight:
1er critère : possibilité de découper le projet en lots (découpage structurel) et/ou en phases (découpage temporel)Un des principes de l’agilité est de livrer partiellement mais rapidement de la valeur. Ainsi, on recueille rapidement du feedback des utilisateurs. Plus le projet est découpable en lots suffisamment indépendants, plus il est possible de livrer rapidement et régulièrement des incréments porteurs de valeur et générateurs de feedback. Certains projets se prêtent mieux à ce découpage fin par lots ou par phases ou par priorités … Dans ce cas, la mise en œuvre des approches agiles est plus aisée : livraisons de sprints (incréments de « Scrum® »), de Project Increment (méthode « Agile PM® »), de Program Increment (PI du modèle « Safe® »), entre autres. Au contraire, certains projets ne peuvent pas toujours être découpés en livrables autoporteurs de valeur et cadencés dans le temps. C’est le cas par exemple de certains projets d’infrastructure (ponts, ouvrages d’art…) ou de projets de développement de produits manufacturés. En effet, ils nécessitent la réalisation d’outillages long et coûteux à produire. Pour ces projets, on préfère le mode prédictif. De manière générale, quel que soit le mode d’exécution du projet (prédictif, hybride, agile), il est bénéfique de proposer des livraisons partielles plus nombreuses et plus fréquentes (incrémentales, itératives). Elles permettent en particulier de limiter « l’effet tunnel ». Autre avantage : s’adapter plus facilement aux évolutions de la demande ou du contexte. Donc, il est toujours essentiel de porter au plus tôt dans le projet une attention particulière au découpage du projet sous l’angle structurel et temporel. A lire >> Pour identifier la meilleure approche pour mener un projet, lisez l’article sur les méthodes agile, prédictive et hybride. 2ème critère : stabilité et niveau de maîtrise du besoin et du périmètre du projetPlus le besoin est cernable et stable, plus les caractéristiques de l’approche prédictive seront adaptées. Autrement dit, plus on maîtrise au démarrage le périmètre fonctionnel du projet (les exigences, le cahier des charges, le product backlog …), plus l’approche waterfall pourra être efficiente comparée au mode agile. Ainsi, le mode prédictif est particulièrement indiqué pour les projets dits « compliqués ». Ils peuvent être importants par la taille (des milliers de composants) mais dont la structure peut être décomposée et comprise grâce à l’expérience déjà acquise sur des projets comparables. Sur ce type de projets ou de parties de projets, l’approche waterfall sera souvent plus efficace qu’une approche agile. Effectivement, on sait assez clairement « quoi » faire et on peut plus facilement optimiser les coûts et les délais. Le mode agile est lui particulièrement adapté quand le besoin n’est pas facilement spécifiable. Il peut être mouvant, évolutif, ambigus. On parle alors de projets « complexes ». Le mode agile étant piloté par la maximisation de la valeur dans des contraintes de temps (time box) et de moyens (budget box), il sera dès lors possible de préciser le besoin au fur et à mesure. Attention tout de même aux situations dans lesquelles le « client » n’a pas vraiment pas d’idée de ce qu’il souhaite. Dans ce cas, en mode agile, les équipes de réalisation peuvent alors rentrer dans des boucles de « rework » récurrentes. On se retrouve dans une situation non plus de « complexité », mais bien de « chaos » non productif (cf. matrice de Stacey). 3ème critère : stabilité des moyens / technologies / process pour réaliser le projetPlus les technologies, les moyens, les process (le « Comment ») utilisés par le projet sont stables, plus le mode prédictif pourra être adapté. En effet, on associe souvent le mode prédictif à un engagement formel de l’équipe projet en termes de coûts et de délais (en quelques sortes un « contrat »). Cela signifie que l’équipe doit avoir une connaissance suffisante des moyens, des techniques et des process qui seront utilisés pour produire les livrables du projet. Avec cette bonne maîtrise du « Comment », l’équipe pourra mieux estimer les charges et les délais, ce qui est essentiel en mode waterfall. En mode agile, la notion de « contrat » est moins présente, puisque l’équipe fait au mieux en termes de valeur avec les moyens (« budget box ») et délais (« time box ») qui lui sont donnés. Si les technologies utilisées sont émergentes / nouvelles et si l’approche de réalisation n’est pas bien connue, il peut être plus adapté de fonctionner en mode agile. Ce mode permettra une approche « test and learn » tirant du feedback fréquent de l’utilisation des nouveaux process / moyens / technologies de réalisation disponibles. Vous ne connaissez pas la méthode hybride ? Pour la découvrir et la mettre en pratique, renseignez-vous sur la formation hybride. 4ème critère : taille du projetLes méthodologies agile usuelles (Scrum …) sont facilement applicables aux petits projets (pour une ou quelques « pizza team »). Pour les projets importants, la mise en œuvre du mode agile nécessite un « passage à l’échelle » (Scaled Agile). Cela implique de nombreux nouveaux rôles et des processus supplémentaires (par exemple les nombreux rôles dans SAFe ®). On assiste alors quelque fois à une complexification qui peut dans certaines situations nuire à l’efficience du projet en multipliant les instances, les rituels, les outils… Même si le critère de la taille du projet n’est pas décisif, pour les grands projets, il peut être intéressant que tout ou partie du projet soit piloté en mode prédictif. En effet, ce mode permet de traiter de projet « compliqués » sans multiplier les rôles et les processus de pilotage. Un découpage « macro » du projet (approche WBS) et un pilotage « global » rationalisé (instance de décision, jalonnement …) peuvent assurer une efficacité dans la durée pour les projets de grande taille. Vous voulez être plus efficace, gagner du temps et de l’argent dans votre conduite de projet ? Découvrez la formation Scrum. Elle vous donnera les éléments de base à mettre en place pour travailler par itération et corriger la démarche engagée aux bons moments dans l’avancement de vos projets. 5ème critère : possibilité / facilité de revenir en arrière aux différentes étapes du projet (réversibilité)Un des avantages du mode agile est la possibilité de faire évoluer le besoin tout au long du projet. A contrario, dans le mode prédictif, le process de validation des demandes de modifications peut s’avérer « rigoureux », voire « rigide ». Dans le cycle de vie du projet, des modifications / évolutions peuvent entraîner des augmentations de coûts. Les délais peuvent aussi être sensiblement impactés. Ces surcoûts/sur-délais associés à des « retours arrière » peuvent être totalement prohibitifs pour le projet. En effet, ils peuvent correspondre à des coûts associés à la destruction, à la déconstruction, au « decommissioning » de ce qui avait été réalisé. Et ce, en plus des coûts de « reconstruction » / « rework » des livrables en lien avec les nouvelles demandes. A titre d’exemple, des projets qui nécessitent des travaux matériellement lourds et structurants pourront être traités en mode prédictif, au moins sur une partie du cycle de vie du projet. Cela concerne des projets comme « couler du béton », « fabriquer un outillage long et couteux », « déployer une infrastructure SI »… Ce mode waterfall se base sur un approfondissement en amont des spécifications. Par conséquent, il limitera les potentiels « retours arrière » longs et coûteux (ex : recommander du matériel …) L’approche agile sera lui plus adapté quand le « coût de la réversibilité » reste supportable. 6ème critère : contraintes réglementaires & normativesCertains livrables de projets peuvent être sous le coup de contraintes légales / réglementaires très strictes (ex : secteur aérien, pharmaceutique…). Des règlements peuvent exiger par exemple la nécessité de disposer de spécifications complètes auditables avant même d’engager la phase de réalisation. D’autres exigent le respect de phases / jalons obligatoires avec des contrôles stricts associés… La mise en œuvre des principes de l’agilité peut être rendue difficile voire impossible quand l’exécution du projet doit être absolument conformes à ce type de règles. Quand il s’agit de délivrer un projet « compliant », on privilégie le mode prédictif. Vous trouverez dans le prochain article de cette blogsérie, la suite des critères d’analyse. A suivre donc !
Scoop.it!
Cost overrunA cost overrun, also known as a cost increase or budget overrun, involves unexpected incurred costs. When these costs are in excess of budgeted amounts due to an underestimation of the actual cost during budgeting, they are known by these terms. Cost overruns are common in infrastructure, building, and technology projects.
|
Scoop.it!
Many people dread Triage Meetings and perceive them as a waste of time. In this article, we'll discuss how to give your Triage Meeting value.
Scoop.it!
ABC/ABM : Ou comment intégrer une démarche de pilotage par les processus Ce dossier va vous permettre de vous familiariser avec les grands principes de la méthode ABC/ABM. Origine de la Gestion par Activités La Gestion par Activités s’est développée depuis une quinzaine d’années aux USA
Mickael Ruau's insight:
Avantages sur les méthodes analytiques classiques Si la comptabilité analytique fonctionne à peu près dans un environnement très industriel (avec une forte proportion de coûts directs), elle n’est plus du tout adaptée dans le secteur des services (du fait de l’absence quasi totale de coûts directs).
Inconvénients et riques
L’adéquation de l’outil avec l’entreprise st donc fonction non pas de la méthode de contrôle de gestion employée, mais de la manière de la mettre en place !
Scoop.it!
Normes en management de projet, programme et portefeuilleLe management de projet, de programme ou de portefeuille [de projets et programmes] fait l'objet de documents normatifs génériques ou sectoriels élaborés dans le cadre de commissions internationales et/ou nationales. L'objet de cet article est de présenter les documents normatifs élaborés par le Comité Technique 258 de l' ISO et la Commission 620 de l' AFNOR et publiés en langue française.
Mickael Ruau's insight:
Normes ISOISO 10006 « Lignes directrices pour le management de la qualité dans les projets ». Cette norme décrit les processus nécessaires à l’application des principes de la qualité dans les projets et programmes (publiée en novembre 2017)1. ISO 21500 « Lignes directrices sur le management de projet » (publiée en septembre 2012, en cours d’actualisation)2. ISO 21503 « Management de projets, programmes et portefeuilles – Recommandations pour le management de programme ». Cette norme précise les concepts de programme et de management de programme, donne les prérequis nécessaires à la mise en place d’un management de programme et précise les processus à mettre en place pour bien manager des programmes (publiée)3. ISO 21504 « Management de projets, programmes et portefeuilles – Recommandations pour le management de portefeuilles » (publiée en juillet 2015)4. ISO 21505 « Management de projets, programmes et portefeuilles – Recommandations pour la gouvernance ». Cette norme décrit le contexte et fournit des recommandations reflétant les pratiques actuelles concernant le cadre et les principes de gouvernance des projets, programmes et portefeuilles (de l'avant-projet jusqu'aux évaluations après la fin du projet) (publiée)5. ISO 21508 « Management de projets, programmes et portefeuilles – Management de la valeur acquise (Earned Value Management - EVM) en management de projet et de programme ». Cette norme précise l’intérêt de mettre en place un système de management basé sur la valeur acquise et en précise les différentes étapes (en création)6. ISO 21511 « Management de projets, programmes et portefeuilles – Organigramme des Tâches en management de projet et de programme ». Cette norme a pour but de compléter l’ISO 21500 «Lignes directrices sur le management de projet», et l’ISO 21503 « Recommandations pour le management de programme », en indiquant des lignes directrices et les meilleures pratiques pour l’élaboration et la mise en œuvre d’un organigramme des tâches (en création)7. Nota bene : les normes ISO sont publiées en France sous les références NF (ex.: NF ISO 21500).
Scoop.it!
Gestion de projetLa gestion de projet ou management de projet est l'ensemble des activités visant à organiser le bon déroulement d'un projet et à en atteindre les objectifs. Elle consiste à appliquer les méthodes, techniques, et outils de gestion spécifiques aux différentes étapes du projet, de l'évaluation de l'opportunité jusqu'à l'achèvement du projet.
Mickael Ruau's insight:
Démarches particulièresDémarche par motif de conceptionLa gestion de projet est un art difficile dans lequel le chef de projet doit improviser au mieux. Aussi, pour diminuer les risques ou maintenir l’entropie du projet à un niveau raisonnable, l’expérience met en évidence des grands principes. Alan Davis a répertorié 201 principes17 qui s’appliquent aux projets logiciels. Par ailleurs, James O. Coplien offre un aspect du phénomène de Gestion de Projet centré sur les pratiques18. Une pratique est une mise en application formelle d’un principe qui est comparable à un motif de conception utilisé en développement logiciel. En ce sens, la méthode Extreme programming propose elle aussi des pratiques telles que :
Ces pratiques viennent fournir des guides autour du découpage organisationnel choisi. Selon la méthode Agile18, tout comme les Design Patterns logiciels peuvent être liés entre eux, les Design Patterns Organisationnels sont organisés entre eux sous la forme d’un graphe et ainsi un langage organisationnel. Ces motifs correspondent alors à des outils à la disposition du Chef de projet qui sont comparables aux gammes du musicien. Ce langage permet de choisir l’organisation (le motif) qu’il est possible d’intégrer dans l’équipe-projet. Ce choix restreint s’explique par un phénomène similaire à la culture d'entreprise. En entreprise, le changement est la chose la plus difficile à gérer. L’entreprise en a besoin, les individus la rejettent. Bien que ce rejet s’explique par le principe de plaisir (qui est un principe d’économie d’énergie opinion méritant plus d'explications), on constatera que la gamme la plus agréable pour les personnes qui composent cette équipe consiste à réaliser les transitions les plus simples possibles[réf. nécessaire]. Ainsi, tout comme il faut peu de lignes de code pour passer du Singleton au Design Pattern Factory, le passage de la pratique programmation en binôme nécessite peu d’effort pour obtenir la pratique Appropriation collective du code (le code appartient à tout le monde).
Scoop.it!
A RAID log is a project planning tool that focuses on four key areas: risks, assumptions, issues, and dependencies. Risks are events that could have an adverse effect if they occur, assumptions are things you assume will happen to contribute to the project’s success (and that will have negative consequences if they don’t occur), issues are risks that have already occurred and had a negative impact on the project, and dependencies are things that must start or finish so your project can progress. RAID logs are often used when beginning a new project, but they’re also useful for promoting alignment and sharing status for projects that are already underway.
acjahan@gmail.com's curator insight,
November 21, 2019 3:00 PM
Un nouvel outil pour démarrer un projet
Scoop.it!
Cela m’a pris beaucoup de temps avant de réaliser un détail intéressant à propos du projet qui a été décrit au début de cet article. Il a abouti au bout de 190 semaines de travail, après que nous l’ayons examiné en détails pendant 130 semaines. 190/130 est égale à 1,46, soit très près de √π ! C’est magique. Jetez donc un coup d’œil et voyez comment ces quelques réflexions peuvent venir correspondre à votre quotidien. Auteur : Alistair Cockburn Traducteur : Nicolas Mereaux
Mickael Ruau's insight:
2ème partie. Pourquoi ça marcheOK, pour être honnête, je n’en sais rien. C’est ce qui est magique dans ces chiffres magiques. Mais je vais y ajouter quelques observations et voir si elles ont du sens. Vous allez en fait à 1/3 de la vitesse à laquelle vous pensez que vous iriez. N’avez-vous jamais fait une liste de chose à faire le samedi ? Vous savez comme :
Et vous courrez dans tous les sens toute la journée comme un maniaque, et à la fin de la journée vous grommelez “Bon sang ! Je n’ai même pas fait la MOITIÉ de ce qu’il y a sur ma liste ?” La prochaine fois que cela vous arrive, considérez les choses sous un autre angle : avez-vous fait 1/3 de votre liste ? Si oui, considérez alors que cela a été bonne journée. Et félicitez-vous en. Cela arrive très souvent que nous allions / accomplissions à 1/3 de la vitesse à laquelle nous pensons que nous irions. Il y a souvent 3 x plus de tâches à l’intérieur d’un nouveau projet que ce que vous pouvez visualiser. Imaginez que vous faites une liste de toutes les choses que vous devriez faire pour pouvoir faire qu’une partie d’un travail particulièrement compliqué.
Le fait est, que lorsque nous pensons aux choses à faire, nous passons sur bon nombre de petites choses, nous oublions les préparations avant, le nettoyage après et ce qui se passe entre. Pour beaucoup (si ce n’est la totalité) des choses que nous faisons et tout particulièrement les choses que nous n’avons jamais faites, nous arrivons à gérer qu’environ 1/3 des choses à faire sur une liste. En se méprenant d’un facteur 3 sur la vitesse, et d’un facteur 3 sur la taille, vous en êtes d’un facteur 9 soit π^2.
Scoop.it!
La matrice de décision est un outil simple efficace pour nous aider à prendre les bonnes décisions.
Mickael Ruau's insight:
On peut utiliser 3 méthodes :
Scoop.it!
Six Sigma has tools that promote good decision making, which leads to performance improvements that reduce rework and drive benefits to the bottom line faster.
Mickael Ruau's insight:
The final deliverable from this process is to make an educated decision. From the Pugh matrix, it is clear that a file system is the best solution. In addition, there are some positive side effects. The morphological matrix determines the functional requirements. When the team is ready to implement, the functional requirements have been determined. Furthermore, to improve the quality of decision making, the team could perform a risk assessment or failure mode and effects analysis (FMEA) on the selected solution. Advertisement Applying the Six Sigma tools to decision-making does not have to be a long, drawn-out process. In fact, an argument may be made that decision speed is improved because this process limits the solution arguments to team decisions based on data. And, importantly, the foundation for making the right decision is rooting the decision from the voice of the customer.
Scoop.it!
Dans cet article on va donc voir pourquoi notre mémoire n’est pas à 100% fiable quand on prend des décisions, et comment documenter notre processus de décision pour éviter cela.
Mickael Ruau's insight:
Pour conclure voici les 2 grandes idées à retenir de cet article :
Scoop.it!
Dans l’article précédent nous avons partagé les constats suivants : Il existe différents modèles de personnalités qui nous permettent de mieux cerner nos styles et nos traits de caractère. Le modèle ProcessCom® propose 6 styles de personnalité que chacun de nous peut mobiliser
Scoop.it!
Dans l’article précédent « A chacun son style », nous avons partagé les constats suivants :
Scoop.it!
Le RIDA Projet (Relevé d'Information Décision Action) permet de prendre les bonnes décisions au cours d'un projet.
L’objectif du RIDA Projet (Relevé d’Information Décision Action) est de veiller à ce que les personnes concernées par un projet obtiennent les bonnes informations au bon moment concernant l’avancement de ce projet et leur permettre ainsi de prendre des décisions. La répartition efficace de l’information repose sur la sélection des outils et des méthodes adéquats pour atteindre les membres d’un même projet afin qu’ils puissent évaluer les résultats d’une action et/ou prendre des décisions.
Mickael Ruau's insight:
Qu’est-ce que la méthode RIDA Projet?Les réunions de projet impliquent souvent des questions, de longs débats et surtout des décisions commerciales. Malheureusement, après la fin de la réunion, les discussions et les décisions peuvent être oubliées par ceux qui y ont assisté, ou mal interprétées par d’autres personnes qui n’ont pas assisté à ces réunions. Pour éviter de futurs malentendus, un rapport connu sous le nom de RIDA est une excellente méthode pour enregistrer les questions, les sujets de discussion et les décisions. Pour faciliter sa lecture, divisez les temps de réunion en quatre ou cinq sections avec des sous-titres afin que les destinataires puissent rapidement rechercher les informations les plus importantes. La méthode RIDA doit être basée sur: I = Le type d’Information à distribuer La méthode RIDA Projet est centrée sur votre public, l’environnement, les politiques de l’entreprise et/ou l’accès aux logiciels, la taille du projet ainsi que d’autres facteurs.
|
