Here are questions and answers from students regarding Chapter 1.
**Q. My question over module one has to do with the "stakeholders"
described on page 10. I can see why the client, parent organization and the
project team are stakeholders, but I do not necessarily agree with the public
being a stakeholder. Isn't the public the client of any project where the interests
of the public are inherent? I think adding the public as a separate stakeholder
just makes a project more complex. My only experience with an example of this
is with the NEPA process. I tend to see the public as a "task" more
than a stakeholder in that example though.
A. An operative definition of "stakeholder" is "anyone who can
screw up your project." That is very different than "client."
Within the universe of stakeholders, you might differentiate stakeholders who
have a legal relationship with the project from stakeholders who are just out
there. Within both "client" and broad groups such as "the public,"
you need to differentiate further. Often within the client's organization are
very different stakeholders, the maintenance department vs. the purchasing department,
for example. Also, it is not necessary and often not possible to "satisfy"
all the stakeholders. But they all need to be "considered."
Q. Suboptimize. Does the term mean: A)That the whole project is below optimal,
or B.) The a subcomponent of the project is optimized.
A. Here's a site that goes into the philosophy of suboptimization:
http://pespmc1.vub.ac.be/ASC/SUBOPTIMIZA.html
They are talking about components, but the principle is the same. Your authors
were just indicating that the functional managers, if it is not "their"
project, will not give it full support.
Q. Also, regarding the author's statement that "performance and schedule
are more important than cost during all stages" of project management (P15).
I ask to who are these more important? While I agree that there are situations
where this may be the case, as in the emergency response during following 9/11.
Which I would argue to be a project as it has the characteristics of being a
one time (hopefully) activity with a well defined set of desired end results.
I would also argue that in most normal activities cost is the most important
factor with schedule and performance taking second place. For example, I have
been told that the Alaska DOT uses a life cycle cost ranking of projects which
is used to determine what construction projects will be funded. While performance
and schedule are a part of this decision making process, it seems that they
are translated into cost for the purpose of deciding which projects will get
built.
Nothing in my experience leads me to believe that the author's statement prioritizing
performance and schedule over cost is in general true.
A. In the author's defense, he refers you to Chapter 3 where we talk about these
issues some more. What he means by "important" here refers to "important
to the project manager," that is, what can the PM change or do anything
about? Costs are often the most worrisome item, but the one that is least controllable,
after the project is started. Many of the author's examples come from "functional"
organizations, the ADOT is very much a "projectized" organization,
and you may notice that leads to different viewpoints, sometimes.
Q. The text states that Project Management came from the military. Yet, this
is an authoritarian group where orders are to be obeyed and orders are passed
down the ranks to the people doing the tasks. A Project Manager must use persuasion
and negotiation to achieve the performance required. How did Project Management
evolve from authoritarian to persuasion? I can't see the transition.
A. The military use of project management was not with command and control of
troops, but rather with weapons development projects and to some extent "operations."
Q. As mentioned in the text, the project manager has to be aware of the "ever
present goals of meeting performance, time, and cost…throughout the project
life cycle. Theses are the same constraints in engineering design - cost, quality,
and time. The best one can hope for is two of the three or an averaged reduction
in all three. I assume this is the case in project management also.
A. "On time, under budget and to the client satisfaction," all the
time, that's us. You work for a consulting engineer and to you the "project"
is the activity that results in a set of plans and specifications. Those plans
and spec's are your "product." The project, from the owners point-of-view,
is the set of activities that results in the completed edifice, of which your
plans and spec's are only one component. Usually there is a tradeoff between
time and money and the quality of the complete product, as well as the time
and money for the entire project. Clearly, you want to minimize time and cost
and maximize production. For the project manager, we are concerned that you
understand the relationship between the three, rather than try to minimize one
and maximize the other, which will be specific to each type of project.
Q. The concept that the project management increases the organizational complexity
in a company is indeed counterintuitive (as stated by on of your previous students).
The main reason I think things would be simpler is the existence of only one
point person; one that can keep the objective clear and in the crosshairs at
all times; one that anybody can come to in order to get some info or where to
look for that info. After the company has gotten past organizing for the project
management technique, shouldn't things be simpler?
A. For a "projectized" organization, each project needs a project
manager, so complexity is not an issue there. (One PM might manage several projects,
though.) For a "functional" organization, the notion of projects and
project managers contributes to complexity. As long as each function has its
own turf, the relations between the functions in clear and the authority of
the functional manager is clear. When a project is introduced, it typically
cuts across the functions, and the authority of the project manager is not clear,
vis-à-vis the functional managers.
Q. For some time I wanted to design and build aircraft and that was one reason
I pursued engineering. Then I spoke with high school friends who had gone to
work for Boeing and Northrop. They were struggling because they would have a
job for 2 or 3 years while their project lasted and be on the street for a year
or more and then get another short position. It seems like aerospace is a project
based industry except for a few administrative positions. This seems wasteful
and hard on the employees. There appears to be no way for these guys to build
seniority or retirement. Perhaps it was just because they were so low on the
totem pole. One of them spent 3 years in a tiny cubicle drafting bolts, that's
all. I suppose if he has lived through that he is now doing some design. Is
it good for the organization to constantly cull the workforce? I can see why
it would be profitable to keep talented people's salaries low but then they
eventually get sick of it and move to the competition or to some process industry
with a more normal lifestyle.
A. Yes, uncertainty is a big part of certain types of projects. Those companies
have functional divisions that build aircraft. They also have R&D divisions
that have projects, sometimes mega-projects, often for the government. When
the project is over, there is not room enough in the functional divisions to
accommodate many of the project employees. One method that is sometimes used
is to hire the project employees under a different type of contract, often with
a large "completion bonus." This bonus inspires the project workers
to stay the length of the project, and also gives them cash, if they must be
let go at the end. We'll hit on the more in the last module on Project Termination.
Q. How does a PM prepare in advance to avoid failure in interdependency relationships?
The high number of variables would seem to doom even the most prepared PM.
A. Here my wisdom may not add anything to yours, but I see the key is to train
the PM to examine these interdependency relationships early in the project,
before they blow up. So you do an org chart that shows the functional interfaces,
and then write in the people's names, and then you ponder. Often a quick hello
meeting of the players at the beginning of each phase will help. There's no
substitute for knowing "who's who at the zoo" when you start a project,
but often it is the minor players, or people who do not come in until later,
who will become major problems.