What We LikedProject risk identification tends to be a negative exercise, especially if the project is in trouble before it even gets going. So in that case, before moving into risk identification and response planning, Rita suggests spending some time on identifying opportunities first to create more optimism.[3] Or you can conduct a "Pre-Mortem" -- like a post-mortem except that you assume project failure and then brainstorm why the project has failed.[4] And, speaking of brainstorming and inputs, Rita provides some very down-to-earth practical advice on how to interview an expert and what questions to ask.[5] Having collected all those risks, the next problem is how to sort them into some sort of order. Rita has a fun exercise for that, too. Write them all up on her custom Risk Notes, layout a large chart on the floor, showing Impact versus Probability, and let the team place them accordingly. Her experience shows that "160 risks can be sorted this way in only 20 minutes ... . Interestingly, only a very small proportion of the risk ratings will need to be discussed."[6] Chapter Seven deals with Risk Response Planning, an area that many people often find difficult, being at a loss for ideas. Again, Rita provides a lot of good suggestions. So, after all of that, there should be no excuse for anyone not knowing how to do risk management! The process of project risk management that Rita describes in her book is well integrated into PMI's more familiar tools and techniques. But she carefully skirts round the troubling confusion in most people's minds over the similarity between the five PMI management process groups of Initiating, Planning, Executing, Controlling and Closing that otherwise look uncommonly like the project life span. She simply states "The project management life cycle follows PMIŽ's process groups."[7] To the extent that the principle project management processes are nested within each phase of the project life span, and indeed within each stage and succeeding breakdown of the life cycle down to the activity level, then the reverse must also be true. Rita categorically asserts, "It is not the project manager's job to create the project charter. A project charter should be issued by management for every project."[8] Good. But management does not always know what to put into a charter so it becomes incumbent on the project manager to provide some input. Indeed, creating your own terms of reference is not a bad thing, making it much easier to reach a meeting of the minds between project sponsor and project leader. Under "Assumptions" Rita talks about "Risk Tolerance Areas" and observes "Tolerance areas are usually expressed in terms of the Triple Constraint: cost, time, scope of work, quality, risk and customer satisfaction."[9] She even illustrates the statement with a hexagonal polygon. Since the Triple Constraint is usually illustrated by a triangle, the reader should not fear a feeling of being mathematically challenged. According to Rita, "One of the top 10 reasons projects fail is that project managers do not adjust their project management process to the needs of each project." And "Project failure can often be attributed to a lack of adaptation of organizational policies." Hence "Tailor Risk Management Activities to the Needs of the Project."[10] Good advice indeed! Appendix Two: Risk Categories and Lists of Risks offers 15 "opportunities" and 491 "risks"[11] -- and the winner is ...?! Still, we enjoyed some of them: Under Design Procurement & Construction we saw that "Local politicos, unruly elements, etc." can be a "Cause" of risk.[12] Well said. We like the implication!
3. Ibid. p71.
4. Ibid. p82.
5. Ibid. pp84-86.
6. Ibid. 110.
7. Ibid. p28.
8. Ibid. p32.
9. Ibid. p39.
10. Ibid. 48.
11. Ibid. pp429-307.
12. Ibid. p254.
|
Book Structure
