In our Introduction, we have already applauded the simple treatment of each topic so that anyone can understand the content. We have also applauded the fact that the authors have come down hard on a basic four-phase project life span. We are also pleased to see that the authors recognize that:
"Any project will be managed by the five project management processes of initiating, planning, executing, controlling and closing. These processes will be used in every phase of the project."
However, this position is somewhat compromised by a subsequent statement that says:
"The project life cycle comprises the stages of a project from beginning to end. There are five phases that can overlap somewhat but generally take place in chronological order. They are, in order, initiating, planning, executing, controlling, and closeout."
And later the authors say:
"For our discussions we will use a generic description of the phases of the life cycle: initiation, planning, execution, control, and closeout."
"The project management processes - initiation, planning, execution, control, and closeout - take place in each of the project phases, and the phases of the project must use all of the project management processes.
We suspect that the authors know which is correct, but it is difficult to imagine how the concept of management control could be more confused.
With regard to the project life span, the authors observe that:
"The project life cycle begins when the project first comes into existence. This usually occurs with the creation and approval of a project charter."
We beg to differ. We believe that you should justify every idea or concept for a project with a Business Case. Approval of the Business Case by management then kicks off the project life span starting with the planning phases of the project. It also enables the creation of a conceptual planning or feasibility budget and a project cost account for collecting the actual project expenditures. For a very large project, it may even be necessary to create a cost account to capture the cost of developing the Business Case itself.
The Project Charter, on the other hand, comes later. This "Execution Bible" summarizes the strategic planning for the project and is presented for management approval of project execution and corresponding funding. This is where the major effort and consumption of resources takes place. However, this discrepancy between Business Case and Project Charter is somewhat understandable, because the PMBOK Guide fails to make the same distinction.
In their introduction, the authors discuss "the project management triangle or the triple constraint?" and then present a figure that displays Cost, Schedule and Scope on the triangle's faces with Customer Satisfaction in the middle. This is yet another variant of that wretched and obsolete triangle.
From the list of chapters in Book Structure, you will note that the PMI knowledge area "Contract/Procurement Management" is missing. This is a pity because even though many project participants feel that they are not involved in "contracting", in fact the principles apply just as much to internal resource commitments as they do to external legal contract commitments.
Perhaps the weakest chapters are Chapters 9 and 11 on Quality and Communications respectively. Both are short and generally describe these topics as applied to management and production management rather than as applied specifically to projects. As a matter of record, the PMBOK Guide's Project Communications Management knowledge area was originally titled Information/Communications Management. It thereby addressed the vital area of Records Management and so encompassed data management, including versioning, storage, retrieval and archiving. Turning to the quality area, we've always thought that only under rare conditions can all that statistical stuff be applied to projects. That's just because projects are unique and typically consist of relatively short-run activities.
10. Ibid, p5
11. Ibid, p6
12. Ibid, p7
14. Ibid, p6