Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Gestion du risque pour les nuls La gestion des risques est une pratique qui vou

Gestion du risque pour les nuls La gestion des risques est une pratique qui vous est inconnue, qui vous semble nébuleuse voir même… risquée? Et pourtant, les éminences du SEI la considère comme une pratique de base et l’ont placée au niveau 2 du CMM! Que faire ? Nous vous offrons un atelier sur le sujet. Vous y apprendrez le B-A-Ba de la gestion des risques et pourrez exercer vos nouvelles connaissances avec vos collègues du SPIN grâce à des études de cas pratiques et vraisemblables. Les participants seront groupés en équipes de 5 à 6 personnes et un animateur chevronné vous sera dédié pour chacun des exercices pratiques. Le tout dans une ambiance humoristique !!! Au menu : pourquoi gérer les risques, qu’est-ce qu’un risque, le risque vu sous l’angle CMM/CMMI, les ressources et références - et le plus important - les grandes étapes de la gestion du risque. Les exercices pratiques couvriront chacune de ces grandes étapes. Diplômé en Informatique de l’université de Sherbrooke en 1988, Daniel Dutil œuvre depuis 17 ans dans le monde du logiciel de gestion et du logiciel embarqué. Il a participé à de nombreux projets de développement de systèmes, d’implantation de progiciel, d’entrepôt de données et d’amélioration de processus. Il a agit successivement à titre de programmeur, d’analyste, de modélisateur, d’architecte, de spécialiste en génie logiciel et en assurance qualité, de formateur, de chef de projet, de gestionnaire et d'administrateur. Il est reconnu comme étant innovateur et excellent vulgarisateur. Il sera assisté de son équipe de G.O. (gens organisés), pince-sans-rire reconnus pour leur pragmatisme, leur débrouillardise et leur expérience de la vraie vie! Lucie Michaud, M.B.A. Madame Michaud est conseillère principale pour le Groupe LGS inc. Elle œuvre en informatique de gestion depuis 20 ans et excelle en gestion de projet et de personnel. Son expertise inclus entre autres: la gestion de projets de développement informatique ou d’infrastructure technologique, l’amélioration des processus et le conseil en management. En plus des postes reliés à l'informatique, elle a travaillé à titre de gestionnaire de produits financiers et de directeur de comptes commerciaux ce qui lui a permis d’appliquer la gestion de risques en milieu d’affaire. John Slavich, M. Ing. Graduated with a Master’s Degree in Electrical Engineering – Software Engineering, from École Polytechnique de Montréal, John Slavich is now the founder of SPI Link Inc, which specializes in software development processes and software subcontract management. He possesses an extensive knowledge of software development practices as well as Six Sigma methodologies applied to the railway industry. In fact, John is trained in Six Sigma and DFSS and has led one of the first DFSS projects applied to software where he evaluated the risks associated with embedded software subcontractors during railroad projects. His main interests include finding solutions for improving subcontractor management and embedded system development processes through a modified Six Sigma approach. Gestion du risque pour les nuls Si simple ! SPIN de Montréal Daniel Dutil, SPI Link inc. SPIN de Montréal - 20 octobre 2003 2 Pourquoi gérer les risques – Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified. – Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified. – Resolution Type 3, or project impaired: The project is canceled at some point during the development cycle. Tiré de: http://www.pm2go.com/sample_research/chaos_1994_1.php SPIN de Montréal - 20 octobre 2003 3 Qu’est-ce qu’un risque • Un risque est un événement qui met en péril l’atteinte de nos objectifs de: – Coût – Échéancier – Performance (requis: techniques, de qualité du produit) • Afin d’uniformiser l’identification, nous utiliserons toujours le format suivant: [Le risque], suite à [l’événement déclencheur/la cause] résultera en [la/les conséquence(s)]. Ex.: Le départ de ressources humaines critiques, suite à des offres financièrement plus intéressantes, retarderait d’au moins 2 mois l’échéancier. SPIN de Montréal - 20 octobre 2003 4 Quelques excuses… 1. We have no risk. 2. Give us an hour and we’ll tell you our top ten risk items. 3. Making risks public will kill the program. 4. The customer goes ballistic whenever he/ she hears of a potential problem. 5. We deal with problems as they arise. 6. My customer doesn't want to hear that he/ she is the source of risk. 7. Identifying risks is bad for my career. 8. This is development— why should we worry about supportability and maintainability risks? 9. How can you predict what will happen a year from now? 10. Our planning horizon is six months. 11. No one on the staff knows how to do risk management. 12. We plan to start implementing risk management next year, after we define the process and train the staff. 13. Our job is to develop software, not fill out bureaucratic forms. 14. The commercial software industry doesn’t waste time on risk management. 15. We don't need a separate risk management program because we have frequent technical interchange and Integrated Product Team (IPT) meetings. 16. If I gave a realistic assessment, no one would listen. 17. That external interface is not in our risk management program because the interface is not our responsibility. 18. Using that tool is not a risk. The vendor’s salesman said so. 19. That method is proven and therefore not a risk. The speaker at the conference said so. 20. People outside the project who don’t understand the context will invent worst- case scenarios. 21. The program is too small to do risk management. 22. Corporate management won't buy in. SPIN de Montréal - 20 octobre 2003 5 Quelques excuses (2)… 23. My tech people will rebel if we identify as a risk betting our success on an unproven new technology. 24. My tech people will rebel if we identify as a risk a lack of skills needed to do development. 25. We have no cost or schedule risk because new technology will enormously increase our productivity— by five to ten times. 26. New technology we have never used before will mitigate the risk. 27. We have to bid the lowest cost to win; we'll worry about doing the job when we get it. 28. If we bid everything we do, we would lose the project. It’s a delivery- order contract. 29. We can’t identify risks based on industry metrics because our process is different. 30. You have to cut corners to win the program. 31. We don’t mitigate software risk in systems engineering trade studies for embedded systems because software is only a component of subsystems. 32. Our methodology is Rapid Application Development (RAD), so we have no schedule risk. 33. Our methodology is evolutionary development, so requirements volatility is not a risk. 34. We don’t include anyone from our hands- on software development staff in risk identification because we have hired an outside consultant as a risk expert. 35. We don’t include anyone from our hands- on software development staff in risk identification because our managers are using a generic risk database to identify risk. 36. We don’t include anyone from our hands- on software development staff in risk identification because they don’t have the big picture. 37. A prime contractor is not behaving like a prime if people from a subcontractor organization participate in risk identification. 38. There is no risk in the planned big increase in our software staff because of the large layoffs by defense contractors during the past few years. Tiré de: The Little Book Of Bad Excuses, Software Program Managers Network SPIN de Montréal - 20 octobre 2003 6 Un palmarès des risques • Personnel shortfalls • Unrealistic schedules and budgets • Developing the wrong functions and properties • Developing the wrong user interface • Continuing stream of requirements changes • Shortfalls in externally furnished components • Shortfalls in externally performed tasks • Real-time performance shortfalls Tiré de http://www.ece.ubc.ca/~elec443/lectures/risk.pdf SPIN de Montréal - 20 octobre 2003 7 Une taxonomie (SEI) http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html B. Development Environment 1. Development Process a. Formality b. Suitability c. Process Control d. Familiarity e. Product Control 2. Development System a. Capacity b. Suitability c. Usability d. Familiarity e. Reliability f. System Support g. Deliverability 3. Management Process a. Planning b. Project Organization c. Management Experience d. Program Interfaces 4. Management Methods a. Monitoring b. Personnel Management c. Quality Assurance d. Configuration Management 5. Work Environment a. Quality Attitude b. Cooperation c. Communication d. Morale A. Product Engineering 1. Requirements a. Stability b. Completeness c. Clarity d. Validity e. Feasibility f. Precedent g. Scale 2. Design a. Functionality b. Difficulty c. Interfaces d. Performance e. Testability f. Hardware g. Non-Developmental Software 3. Code and Unit Test a. Feasibility b. Testing c. Coding/Implementation 4. Integration and Test a. Environment b. Product c. System 5. Engineering Specialties a. Maintainability b. Reliability c. Safety d. Security e. Human Factors f. Specifications C. Program Constraints 1. Resources a. Schedule b. Staff c. Budget d. Facilities 2. Contract a. Type of Contract b. uploads/Management/ gestion-du-risque-pour-les-nuls-sa-tin.pdf