Downside
There is very little in this book that we can quarrel with, other than it should make clear that it is talking about projects in the high-tech arena. However, in this regard, it takes a refreshingly new look at what it takes to become proficient at project management and makes it clear that it is not simply a question of passing a certification test. Still, we did take issue with a few minor points, especially in Chapter 1.
Author Ronald Cagle says that over the years he has developed a formula that expresses success in project management. He suggests that the path to it can be expressed by a very simple formula, although actually achieving that success is not quite so simple. The formula is:
(Knowledge + Experience + Persona) x Performance = Success[9]
This is an interesting conceptual construct. However, without providing some fundamentals and metrics for the five variables involved it remains only a concept as a basis for discussion.
In describing "Projects and Programs", Ronald differentiates between the two by explaining: "A project is performed for an in-house customer; a program is performed for an out-of-house customer under the aegis of a legal contract."[10] Perhaps Ronald's company has chosen to define the terms that way, and they have every right to do so if they so wish, but that is not consistent with the generally recognized definition and could well be confusing for neophyte project managers. The essence of the accepted definition is: "A group of related projects that are managed together." In other words, a program is simply a set of connected projects regardless of who does them.
The use of the terms "phases" and "stages" appear to be interchanged. We believe that stages are subsets of phases. This leads to some confusion in a diagram depicting "Relationships between the stages and phases"[11] in the life spans of programs and projects. Then, in text that follows, a "Closure Stage" is described but does not mention the important business of transferring the product into the care, custody and control of the customer.
Elsewhere, Ronald recounts a personal story as follows:
"Suppose you are offered a position that is within your capabilities, and everything looks great. In fact, everything is too great. During the negotiations you double your present salary, and the interviewer doesn't even blink. You request some heavy-duty requirements such as an extended household move, and still the interviewer doesn't even blink. Something is not quite right here. This happened to me once. Fortunately, I had enough contacts to find out that the program I was to take over was a disaster, and there was no way anyone could revive it. I found out that they were looking for someone to blame for the failure. I turned down that position."[12]
This sounds to us like an unlikely story, or at least a little exaggerated.[13] But in any case, in our view, this was the wrong approach and wrong answer. Later in the book, however, Ronald discusses "Taking Over a Project" under various circumstances, including "You are hired for an on-going project that is in trouble". In that part of the book, he says: "Hopefully, you had an opportunity to find out the condition of the project before taking the job, but this does not always happen. No matter what, you must still get your arms around the situation before going any further."[14]
We've faced this situation ourselves. We believe that the right answer is that you do have the power to find out the condition of the project. Insist on several days to investigate the project, to talk to the people in the front line - they'll know - and to prepare a plan for recovery, including all the resources you'll need. You may have to put your job on the line to do so, but in practice the risk is minimal and the benefit is massive. We know - we've done it! Then go back and present your plan to management. If management is willing to accept it, then, and only then, try discussing salary, or at least expenses.
Why does this work for management? Because if management is really serious about saving the project, and you can do it, they will be relieved to have someone who is competent in project management, and they will be willing to open the purse strings. Why does it work for you? We've always seen problem projects as great opportunities. After all, you can learn from the previous incumbent's mistakes, it will be difficult to do worse and, by comparison, you'll come out smelling of roses!
9. Ibid, p10, 107, 189. In this first edition of the book, the formula is printed without the brackets. The author says this was a typological oversight and will be corrected in the next edition.
10. Ibid, p3
11. Ibid, p4
12. Ibid, pp9-10
13. Note: in the section "Issues & Responses: Downside" Ronald categorically refutes this suggestion.
14. Ibid, pp181-182
|
What We Liked: Use of Unique Parameters
