Introduction | Book Structure | What We Liked
Downside | Summary 

Downside

We would quarrel with part of Rita's description of "Scope Statement". She says: "Think of the term scope statement as another word for the scope of work, ...".[13] In our view the scope statement should describe the project's deliverables, while the scope-of-work should describe the work involved in producing the deliverables, two separate steps. The former determines the latter, but it is the latter that provides the basis for estimating and planning, and where the risks will be identified.

In the Chapter Four sidebar we learn that "Risks include what can go RIGHT (opportunities) as well as what can go WRONG (risks)!"[14] It is true that RAMP Ltd., a UK based organization, defines project risk as "The likelihood of variation in the occurrence of an event, which may have either positive or negative consequences."[15] However, the majority of authors see risk itself as negative but nevertheless see the importance of looking on the positive side as well, i.e. looking for opportunities. We believe that looking for opportunities, or even converting risks into opportunities, is an appropriate part of project risk management, yet others believe that opportunity seeking is really a completely separate activity. It all depends on the phase in the project life span.

There is sure to be some disagreement over how Rita describes time and/or cost "Reserves". She suggests that there should be two reserves: "contingency reserves" to deal with identified residual risks that remain after risk response planning; and "management reserves" to deal with risks that have not been identified.[16] "Management" usually refers to the project sponsor's "management" rather than the project's "management". Hence, this would be beyond the control of the project manager and therefore not part of his or her project until released by "management", typically for a scope change.

In discussing proposals, bids and contracts, Rita suggests that "A contract should not be created without first completing a risk analysis!"[17] However, there is a problem if the contract is to be formed as a result of a firm-price bid or proposal. If none of the competition is including an allowance for conducting a risk analysis, then the proposal is less likely to win on cost grounds. Nevertheless, Rita does point out that "Many of the risks on the project can be eliminated if the buyer and seller work together."[18] The trick is to get that to happen.

We had some trouble with Issues and Workarounds. In the section titled "Create Workarounds" Rita describes an issue as "an unforeseen, minor problem that has occurred. It may be handled by listing it on a project action item list and managing it, or creating a workaround."[19] In our view an issue is any item, small or large, that needs to be resolved -- often at the next higher level, or between two or more parties. It is not necessarily a risk item, but an open question to be resolved.

As to workarounds, Rita paraphrases PMI's PMBOK Guide definition as "an unplanned response to an unidentified risk that occurs. Workarounds are reactive; project management is supposed to be proactive."[20] We don't agree with the PMI definition and, as Rita suggests, see no reason why a workaround should not be planned in advance. I.e. "If that happens, we'll do this to get around it." So, if you create a workaround in this way, it is no longer an unplanned response!

What We Liked

Summary

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page