Issues & Responses: Downside
Issue
"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
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."
Response
I suggest that you consider the construct carefully. There is no value of any factor or no value of the summation of all the factors within the parenthesis that can exceed the performance factor. The whole idea behind this construct is to present the importance of performance being more important than any other or the sum of all other factor in the construct. Program managers that don't perform simply do not last very long. I was surprised during my research to see that the IPMA and, by association, asapm come up with a similar construct.
Issue
"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.' 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."
Response
Actually that is the definition offered by PMI and then absorbed by other organizations that don't care to develop their own.
On pages 27 and 28 I explain that different organizations and different companies have their own definitions of terms but that there is no standard throughout industry on any of the terms. I have been managing programs for many years and the first time I heard of PMI or asapm or the others was about two or three years ago. It's the same with most of the people I talk to. It could be that project management training within a company falls victim to the NIH (Not Invented Here) Syndrome. Whatever it is it seems to work for them. As much as the major PM organizations would like to say that theirs is the standard for all PM they really aren't, at least not yet.
Issue
"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' in the life spans of programs and projects."
Response
I assume when you say "We" you are talking about PMI and when you say "interchanged" you are saying the book presentation versus the PMI's position. Once again, I am not trying to substantiate someone else's position, I am presenting my experiences. I believe this is a worthwhile subject to bring up so long as the reference is to the book and, say, PMI or asapm or the PMI's PMBOK. I don't believe it is correct to say the "standard." I'm afraid that if you got 10 program managers into a room and asked this question you may get 11 answers.
[MW] There is indeed much confusion surrounding this issue - unfortunately. It really would help if we all spoke the same language to the extent possible. Just look at the number of different definitions of the term "project" that you'll find on my Glossary of PM Terms!
Issue
"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."
Response
In some cases of the Closure Stage of each of the Project Types in Chapter 9 the product is mentioned or implied; however, it could be clearer. If there is ever a re-write to this book, that is a subject that should be addressed specifically within each Project Type.
Issue
"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.'
This sounds to us like an unlikely story, ..."
Response
Sorry, but this is a real story. There were three people from three companies involved. The program was a highly classified program. Classified programs in another company (many times even in your own company) do not allow review of the program until the person is "read in" into the program. This is a "cart and horse" situation but that's how it is. Unfortunately this was not mentioned in the text. I'll just have to take my lumps here but, it was a real situation and the point is "don't buy a pig in a poke."
When it is not possible to review a program in progress you have to make your own decisions. Do you want to move to another program and another company so badly that you will take the program on without further consideration? I don't disagree with your recommendation when it is possible to review the program "in the light of day.". See also Chapter 10, Page 162 where I say: "Occasionally, you will be asked or directed to go to the next project or program before finishing the one you are currently working on. Don't lose the opportunity, but first, audit the program you are leaving and have someone of authority agree with the audit.
If your replacement does not conduct the program as well as you did, you have a recognized condition of the program as you left it. It can save your reputation or your job. Conversely, if you are assigned to an ongoing project or program, it is a good idea to audit that project or program as soon as you arrive. Here we have the opposite case in terms of performance but the same case in terms of establishing a baseline. In the case of the ongoing project, it will be difficult to conduct the audit, but you should insist that it be performed anyway."
Issue
"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!"
Response
But you also threw in your own conditions: "... willing to open the purse strings." An on-going program with the federal government just doesn't do that. Under those conditions the government has the company by the shorts and is not willing to let go unless it is an R&D program and is absolutely essential to national security. If this had been the case in the program referenced, they would not be seeking a new program manager.
Certainly I have no argument with your statement, when possible. In fact, please see Chapter 10, first paragraph for a more reasonable, but different approach that I believe, parallels what you are talking about.
[MW] I guess I would differ here. If I'm the program manager charged with getting the job done, maybe the money doesn't come from the Federal Government, but it has to come from somewhere. And where it comes from is not my problem, it is my Director or Sponsor's problem.
|
Issues & Responses: What We Liked
