Downside
In the author's view, "Unless you are coordinating the work of other people, you are not practicing true project management."[22] We don't agree. Many projects do undoubtedly involve the work of only one person and necessarily involve the development of a WBS, a schedule, as well as the cost and risk of the exercise. Surely that is project management, even if it is "self-management"? Indeed, one of the big advantages of introducing young people to project management early in their careers, is to give them the opportunity to learn and practice self-serving life skills.
Conversely, many people in the IT domain, especially those using "Agile" practices, measure their progress by tracking the number of outstanding "issues". Since new issues can surface at any time, by this metric just standing still can represent a lot of work! But because they are not tracking time or cost, does this mean that they are not practicing true project management? By the author's standard, we are inclined to think they are not.
Chapter 9 - Project Control and Evaluation is a very good chapter. However, we do not feel the same about Chapter 10 - The Change Control Process. This chapter is one of the "three notable topics that have been expanded for this [4th] edition."[23] In the first place, in a section titled Sources of Change it talks about that wretched obsolete construct triple constraints triangle, [24] obsolete because a triangle cannot represent the complete project situation. Second, it is stated that: "Project quality is a constant and should always be considered as a potential source and focus of change control."[25] If "Project quality is a constant", then why would it be subject to "change control"? Thirdly, and on the contrary, the basis of project quality and product quality must both be measured against the quality grade that is specified in the project's requirements. And quality grade is a key variable that must be specified along with the project's scope at the outset.
Under a section titled: "The Six Steps in the Change Control Process" the first step is describe as:
"Step 1: Enter initial change control information into your change control log." We are inclined to disagree. We think a better first step is to ascertain whether what is being asked for is in fact a change, relative to the original baseline documents, or is it just a clarification of those original intentions? Asking this question avoids having the change control log cluttered up with a lot of non-starters that tend to make the final record look bad.
In "Step 2: Determine if the change should be processed" we are told that:
"By determining if the change should be processed, you take on the role of the project's gatekeeper. All too often, I have seen project managers accept changes simply because they are requested. If the change doesn't make sense - if it doesn't add value or should not proceed for other reasons - push back. Request clarification or justification to help you arrive at a reasonable decision."
In our view, this is patently wrong. The project manager should never be put in the position of "gatekeeper". That is not his or her job. His or her job is to manage the people doing the work of the project according to requirements. Unless the required change is patently obvious and minor, in other words a "no-brainer", the requested change should be referred to a change control board chaired by the project's owner or sponsor. And, moreover, it should be accompanied by corresponding adjustments in the project's time and cost allowances (see Applying mathematics earlier). Of course such a "Board" might be just one person - provided they have the authority to spend the client's money!
22. Ibid, p7
23. Ibid, p xi
24. Ibid, p126
25. Ibid, p127
26. Ibid, p128-130
|
Some Useful Ideas
