Downside
As we have observed before, producing a book requires a lot of dedicated time and effort on the part of the author or authors.[9] Composing and writing a book is not a trivial project, whereas it is easy to be critical of the result. Moreover, critics often see the opportunity to criticize as an opportunity to brandish their own opinions - and we are no exception.
Up to the 1990s, many practitioners and academics took the view that project management only started when the production work started, that is, in the execution phase. And maybe for most people that was true. However, even in the 1980s we knew that the origin of a project is typically a "need"[10] and that this need might be translated into a project. However, by the time the first decade of the new century rolled around, the large number of "failed" projects, at least those that failed in terms of time and cost, became a serious concern. This was, and apparently still is, especially true in the emerging information technology domain.
Consequently, a better "front-end filter" became imperative. That is to say, there needs to be a way of differentiating and prioritizing those projects that are potentially economically viable and consistent with the corporate goals and objectives. Hence the arrival of the project Business Case - a document to justify funding at a minimum for further investigation as to what should be done, the best way of doing it and the resulting pay back. This has given rise to a new field of study: "Business analysis", and clearly this is an important prelude to any project execution. It helps to know why you are doing the project in the first place!
We think this should be a key element of the Pocket Guide for Experienced Project Professionals.
Chapter 2 of the PGEPP introduces "Managing Your Project and Program Portfolio".[11] To us, this muddies the waters between project management, program management and project portfolio management. In our view, project portfolio management in particular is a different discipline with different objectives and different tools and techniques. This subject should have its own dedicated Memory Jogger - there would be plenty of content to fill it![12]
Nevertheless, Chapter 2 goes on to describe some aspects of project portfolio management but finishes a little lamely without discussing the whole purpose of project portfolio management, namely, the harvesting of the benefits of the products that the projects produce. Interestingly, "Project Benefits Management", like the Business Analysis mentioned earlier, is also emerging as a new area of study.
PGEPP Chapter 3, Tailoring Project Management to Your Project, talks about Customer Needs, Project Success and Adapting Project Management accordingly. These are all difficult areas and, in our view, poorly articulated in much of the current literature. For example, the success of the project may be measured by the extent to which it is completed "on time and within budget". But what of the success of the product, is it producing the expected benefit? On these terms the project could be a great success and the product a disaster. Or, for that matter, vice versa, but which result best fits the "Customer Needs"?
The "Experienced Project Professional" (EPP) should understand that project management cannot exist in isolation. It always exists in conjunction with a particular type of product and the necessary technology involved in creating that product. Moreover, the EPP should also understand that the methodology for managing the project, i.e. the project life span sequence, can and should be consistent across all projects with only the degree of "ceremony" tailored to suit the size and complexity of the project in question. However, the methodology suited to the type of technology involved is quite another matter. That will vary considerably according to the area of project management application. An obvious example is the difference between a project in information technology and a project in engineering and construction.
We have a few other suggestions for this Chapter 3. There should be more focus on the project manager's real task of planning and scheduling future activities and estimating their cost to completion rather than on just status reporting. Instead, this topic (Developing a Forecast[13]) is buried in the section on Planned Value and Earned Value, where the suggested approach is highly unreliable in practice due to the "S" curve effect. We also feel that it would also be worthwhile emphasizing the need for establishing the customer's expectation in terms of quality grade of the product. This is necessary to form the basis for Quality Management.
The remaining chapters of PGEPP deal with specific project management techniques. Here we would like to have seen a section on the issues of setting Contingencies and Management Reserves. These provide the project manager and his or her sponsor respectively with "elbow room". Contingencies and Management Reserves are not the same thing![14]
9. See a previous summary at www.maxwideman.com/papers/two_books/summary.htm
10. Project Management Body of Knowledge, Standards Committee, Project Management Institute, 1987, Figure 1: Typical Project Life Cycle, page 1-3
11. PGEPP, p15
12. See Issacons 1004c1 through 1004c12 on Index page: www.maxwideman.com/issacons/index.htm
and starting at www.maxwideman.com/issacons/iac1004c1/index.htm
13. PGEPP, Chapter 7: Controlling Project Progress, p 104
14. PGEPP, see definition of Reserve on p58
|
What We Liked
