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.