Module 04, Closure
***Q. (Regarding choosing the organization type. This was a very good response.)
A. The strength of functional departments within a company, in terms of technical
expertise and level of manpower will help determine the interface with project
personnel and needs. The support and direction provided by senior management
will influence the organizational makeup, as well as the influence of functional
department heads. [That's a good point, but the big boss might use PM to arbitrate
between several strong functional managers (I don't want that job).] It is also
important as to how multi-disciplined that the project might be, as to whether
all expertise are presently within the company, whether all departments will
need to supply personnel for a coordinated effort, or whether one department
will be providing the bulk of the personnel. [If it's only one department, a
"project" might not be needed.] And.
Q. The least clear item in the module was how one goes about choosing the most
appropriate form of project management, given that one has the opportunity to
do so (I suppose experience will be the best guideline in this respect).
A. It would be very rare for a PM to get to choose the form of management, but
the book's discussion will make you alert to the environment of the project
that may help you adapt when the environment changes. For example if you change
from a client that has a functional organization to a client that has a matrix
organization.
***Q. The muddiest thing in the chapter was the discussion of participative
management and empowerment. I feel like I have a good understanding of the concepts;
however, I thought the book was very poorly written in this section. There were
way too many terms and acronyms thrown around in a small area that it left my
eyes blurry.
A. Give the author a break; he's talking about motivation, the foggiest thing
in management. All those acronyms refer to guru's and fads. The latest motivation
technique rises to the top, and then fades. Look, if I had a psychological,
physiological, or monetary method that would increase motivation even 2%, I
could sell it for billions. Some of methods seem to work, but that is usually
the Hawthorn effect. What most of those acronyms feature is some method of getting
the bosses out of the day-to-day management, and somehow letting the worker
manage themselves. Flattening the organization, self-directed teams, management
by objectives, and the quality circles of TQM are examples of these fads. Sometimes,
for some teams, it works. Otherwise it does not. People are very different,
one worker feels you are abusing them if you inquire about the progress of their
tasks, another worker feels you don't care about them or their work if you do
not inquire about their progress. Most work endeavors require money or other
support. It makes no sense for the boss to say, "You guys figure it out
and go do it." Unless the boss gives those guys the purse strings or other
support necessary to do what the team decides. Bosses almost never do this.
Just as people are different, teams are also different. One aggregation of people
will get a job a done by itself just fine. Change just one member of the team,
and nothing gets done without the boss getting involved. On the other hand,
all these methods can help you understand a little more about human relations
and might give you some tools you can use. [ And another student's comment:
Yes, I definitely think that this Chapter was excellent. What I liked most is
that the author did not miss out one topic called "The project team":
although he should have called it "Participative Management Forms".
I am convinced that top to bottom management is not the way to go in the future
instead much more participative management forms will gain more attention (SMTs,
SDTs, SDWTs, etc.).
***Q. What I disliked in this chapter is the lack of what I would call "Organization
charts and functions". I only found some crumbles here and there. How shall
a project be broken down in different functions? Who is responsible for what?
What are the lines of communication? What is a steep vs. a flat organizational
scheme?
A. Those details would be different on different projects. The concept of "steep"
versus "flat" is a more general concept. A steep organization would
be the infantry of the military: 3 platoons in a company, 3 companies in a battalion,
3 battalions in a regiment, 3 regiments in a division. Two platoons could be
next to each other in the lines, but belong to different divisions. Hence, in
theory, for one platoon to contact the other, the message would have to go up
the chain of command until a common commander was found, then down the chain.
A flat organization would be our faculty. The departments "heads"
were demoted to department "chairs" when the union took over. The
chairs are not considered "management" according to the union contract.
There are about 120 faculty that report the dean, all those faculty are equal.
Q. I am very fuzzy on the Matrix organization. Figure 4-3 confuses me even
more. I don't even know what specific question to ask.
A. How about the learning module, it has a similar diagram, but set to an engineering
organization rather the manufacturing organization as Figure 4-3? The most important
regarding a matrix organization is that each worker bee has two different bosses.
One is the project manager and one is the chief of the worker bee's parent organization.
In the manufacturing business that parent is the functional organization, in
the engineering it is the technical division or branch.
Q. I was wondering why the book thought (on page 161) that it was most important
for the project engineer and project controller to report directly to the PM.
It seems that the other key team members (maybe with the exception of the support
services manager) have just as vital roles that also directly affect the project
goals??
A. Yes, and it all depends on the parent organization and the project. The author's
experiences in manufacturing are different than mine in construction. Many organizations
do keep the "contract manager" or "contracting" in a separate
organization. The principle is that only these contracting people have the authority
to bind the parent, and their focus is on the boilerplate of the contract. While
the engineers are only interested in the specifications portion of the contract.
The parent feels safer if that authority is too far away, like in the PM's office.
*Q. A good answer about the tendency of project professionals to fall behind
technically, followed by my comment:
A disadvantage of the pure project organization has to do with the tendency
of project professionals to fall behind in areas of technical expertise not
used on the project. Name several ways that a project manager might avoid this
problem.
T here are several different approaches each with varying degrees of intensity.
Some engineering publications suggest short classes or seminars to update professionals
on the 'new, current' standards and issues of the day. Others suggest rotating
project professionals to allow them recuperation time in their functional positions.
However this not only disrupts the project but also may reduce the positive
morale and the professionals feeling of closeness with the project, which is
necessary for effectiveness. Pure project management organization also tends
to stockpile technical knowledge. This results in both redundancy and over retention
of assets. The project manager should be aware of and avoid keeping technical
staff past their useful life on the project based simply on the prospect of
"what if." The professional may even wish to occasionally sit in on
conferences, meetings, or briefings of his or her functional department thus
staying abreast of the happenings of 'home base.' While it may not be possible
during the heat of battle of the project, perhaps during the slower segments
of the project, the professional may share his or her time with the functional
department.
A. Very thoughtful answer, but think about this. When an educational opportunity
comes up, two weeks training in another state, whom do I send? My "main
man" who I need desperately? Or do I send someone who is not too busy at
the moment? Likewise, between projects, the company might send someone, but
if I am PM on the next project, I want to get my people on board right away.
So again, the key people don't get to go. It takes some ethics and character
for the PM to send her best people to training, knowing they may be training
to benefit some other PM or some other company. But PM's that have the character
to do that, put the benefit of their workers ahead of their own, at least once
in a while, are more likely to keep good people, in the long run.
*Q. The book does not provide a good breakdown of different tasks performed
by the program manager. I understand the key differences but lack specific understanding.
Usually the program manager is nothing more than a cooperate executive who defines
projects. The program manager is also non-technical. In an ideal project organization,
what is the program manager supposed to be?
A. Good question. "Ideal" depends on what the parent organization
does. Often program managers are chiefly involved with sales and personnel transfers
between projects. For example, a software R & D company might be organized
by major types of clients: government, retail, transportation. Then a program
manger for retail clients will supervise all the projects for retail stores.
The program manager will know the clients and what types of jobs are coming
up, and be better able to transfer team members between her projects, because
she will know what kinds of technical things the team members have been working
on, as related to retail clients. Another common organizing principle is geographic
region.
Q. I work as an air quality inspector, reporting to the air quality compliance
supervisor. There are currently five air quality inspectors in my team (with
different engineering or science backgrounds), one database person, and one-third
of a clerical person (my team shares a clerical person with two other programs
at this time). The exact makeup of jobs within this team changes as needed.
Our annual budget is determined in July (i.e. the start of the state fiscal
year) while our annual goals (e.g. projects) are determined in October (i.e.
the start of the federal fiscal year). My team is part of the air quality program,
which currently consists of four teams. Teams and team members get changed around
occasionally (sometimes voluntarily and sometimes involuntarily), but the goals
of the program remain the same-i.e. to enforce the Clean Air Act. Achieving
our main goal seems to come in the form of changing projects.
There are about a dozen or so programs at ADEC, each with a similar organizational
structure as my program. There are also programs at ADEC (i.e. Division of Administrative
Services) that provides support for such areas as human resource management,
computer support, public relations, statewide public service, and general office
management.
My best guess is that ADEC is mixed organization, whereas the programs in Administrative
Services use the functional form while all of the other programs use the project
form. Now that I spent the time to write this all out (and to think about it),
I am pretty sure that my guess is correct. What do you think?
A. That's a good question. You have a functional organization, similar to the
Miami water and wastewater, but the functions are according to laws or section
of laws you are enforcing. All functional organizations undergo reorganizations
from time to time. Funding cuts or new programs are the main reasons for the
reorg. Now any particular reorg can be thought of as a project, for example,
a move to a new building. The honcho appoints a PM for the move, who drafts
a team, one from each functional area and that's a project. Needs a budget,
too. When you have a major event, you form a team to go to an oil spill, that
is a sort of project, and it would not hurt to think of it as a project. See
the Class Project 2 for more ways to look at this.