Downside
In reading through the book we did feel that it is more suited to project management practitioners working in the information technology and similar domains. While the information and advice for this area of project management application comes across as most valuable and sound, it may not be appreciated by those working in other areas such as construction and infrastructure.
We also got the impression that the reader is assumed to be in the position of a service supplier working under contract. For example, see What Must Happen for Stakeholders to Consider a Project Successful, Figure 2.[16] If this is true, then from the owner or sponsor's point of view, their project is already well down the line in the execution phase.[17] The effect of this difference is that in the former the extent and quality of information on which the project is based should be much more reliable and hence amenable to the application of the tools and techniques described in the book.
Figure 2: What Must Happen for Stakeholders to Consider a Project Successful[18]
In the latter, however, the quality of the data is much less certain. This is not to say that the need for thorough planning is any less important. On the contrary, such planning needs to be properly revisited as better data becomes available to avoid the misconceptions, confusion, and miss-communications that otherwise build as the project proceeds into the execution phase. The authors emphasize this point by discussing "Fact-based Management"[19] and later, instead of milestones they talk about "Planning Using Inch Stones".[20]
For the owner/sponsor, we believe that it is vital to emphasize the need for a project owner's Business Case to justify the project in the first place. This sets the stage for the project to follow a logical Total Project Life Span such as that shown in Figure 3.[21]
Figure 3: The generic Total Project Life Span
Returning to the issue of how stakeholders consider a project successful, Figure 2, the problem is that certain key stakeholders, such as the owner, sponsor, users and observers generally do not view success in the same way. They look at the resulting product and ask the question: "Did it work and did it make money?" In other words, did the product produce the intended benefits? If not, the project was not a success. In short, we suggest that Figure 2 would be more inclusive if it included a final column covering the Benefits Realization phase of the product life cycle.
To their credit, the authors cite a case in which the project produced "an exceptionally, high-quality product on time and within budget ... and the company made a profit". However, they suggest that some could still consider this project to be a failure on the grounds of excessive overtime that resulted in an exhausted team. Our experience is that overtime is often invoked because of the amount-at-stake by the end of the project and the team may be exhausted - but nevertheless happy to be done successfully.
Finally, the authors list Scope Creep as one of the Key Factors Leading to Failure "and is one of the major reasons that projects get out of control."[22] While this is unfortunately true, we don't go along with their assertion that: "This scope creep occurs on all projects ...".[23] We suggest that scope creep, as defined in the glossary, should not occur on projects that have properly implemented management controls. This has been the case for many of the projects we have worked on. However, your experience may be different depending on the type of project and your definition of "scope creep".
16. Ibid, Figure 1-2, p14. See in particular first two columns in last two rows.
17. The authors state that this is not their intent.
18. The authors agree that this is a very important figure. They do not agree that benefits realization, did it work, did it make money, did it produce the intended benefits, are beyond the control of the categories of stakeholders that are listed.
19. Ibid, p57
20. Ibid, p71. "Inch Stones"? We like to think of them as "Inch Pebbles"!
21. In the authors view, the verbiage provided here is not very insightful. In fact, they think that Figure 3 should be omitted from the discussion since it does not provide useful information. Instead, they would prefer to see additional positive comments about areas addressed in the book.
22. Ibid, p13
23. Ibid. The authors define scope creep as "The acceptance of new requirements and changes to requirements without any control or management" - Glossary p216
|
What We Liked
