Module 06, Closure

ESM 609 Closure

Q. The muddiest thing to me had to be the quiz. I searched unsuccessfully for an hour and a half to find precise answers to questions two and three. I settled on none of the above and all of the above respectively. Even after I saw the "correct" answers I couldn't find definitive support for them in the text. Now, with that whine out of the way - in this chapter the author referenced numerous other works. At times it seemed as if he was trying to at least minimally touch upon all planning options and it was confusing which ones he thought were optimal. The paragraph on TREND is a good example. It was intriguing but incomplete. And I don't have the time to look up Benningson, 1972. I also wonder about the value added from vaguely referencing a 30-year old publication. Was this just a historical footnote?
A. Ahh! You are discovering something about management, or the teaching of it. Management education is dominated by "fads and gurus." Most of the theories are not really testable. And, even if you can do some research, you can never be sure if you are observing the method, or the individuals. Now the take home message from Section 5.5 (and 5.3 and 5.4) is that you must PLAN for the interfaces. You cannot assume they will take care of themselves. The TREND chart is just one tool that may help you determine the interfaces. From these, you would develop a procedure list, for example, who gets copied with memos and who gets invited to the meetings. Figure 5-11 might get a little more clear if you realize that the square boxes are people and the ovals are processes. For example, starting at the "design team" box toward the center, you see they are responsible for "chip design," and further that "Schematic" is one of the outputs of "chip design." Now you see that the schematic must be sent to the "chip manager." She will "Review and contribute" before it is used in the "chip schedule," and so on.

Quiz question 2, about elemental project descriptions.
Page 194 is fairly explicit about this, but the philosophy is several other places in the chapter as well. The lower levels of planning are more detailed and should be done by lower levels of management. It is unlikely that upper mangers will be knowledgeable about all the project areas in detail. So if upper mangers try to plan all the details, they will plan those areas they are familiar with in detail and not pay enough attention to the areas with which they are not familiar.

Several Students noted that this chapter deals with a complex subject either superficially, or by trying to present a "cookbook approach to very complicated problems. You might enjoy these students takes on the issue.

Q. Until now I found this book well written and well balanced. Unfortunately this chapter leaves a different impression on me.
In the first years of my career I was working as a planning engineer. Therefore, I had to get well familiarized with this topic. When reading the chapter, I get the impression that the authors just compiled their info from literature but never did any kind of planning work themselves. The approach chosen in the book is far too diffuse and unspecific.
    In addition, it seems that they have only small-scale projects in mind (although the examples are of a different nature). Project planning does not consist just of time scheduling and linear responsibility charts. In reality time scheduling is just a tool among others. In complex projects, project planning comprises at least budgeting, contract administration, and procurement elements. Project planning is "the glue" that holds them together and prevents the project from falling apart.
    Another aspect, that I wished the authors had discussed more, is what really concerns planning engineers most and that is the many and very often contradicting demands that they have to satisfy during a project cycle. Here an example of what I mean:
The output of the planning engineer is used by the headquarters project executive committee, client, consultant, authorities and project team, and in a later stage, arbitration courts (in case of claims) simultaneously or consecutively. The planning engineer needs to keep them all happy and realizes that this is a non-achievable goal! Why? Because all parties involved have different interest and steaks in the project. In addition, planning is misused in a large extend as a tool to put blame on others.
   Pretending that planning is just an academic exercise is certainly not the right approach in a book bearing the subtitle on the front "A Managerial Approach".
A. The authors try to explain planning, the most important and difficult part of most projects, in less than 30 pages. I don't think they did a bad job of it. I agree they imply that by using these charts or processes, the planner can make everything work smoothly. For example: You give the functional manager a plan, that calls for that manager donating 5 key people to the project 9 months from now. A week later you ask him if the plan is "OK with him." If the functional manager says "Yes, of course." That probably means one of two things. Either the manager did not read the plan or he has 5 lemons that he has been trying to get rid of for years. However all this type of uncertainty and chaos are described elsewhere in the book, and described quite well in most cases.

Q. When acting as a PM, much of the planning and day to day operation will be by 'seat of the pants'. It would be nice to know whether the information presented will be of value when the project is progress fast and furious. I try to constantly ask myself: "Can I use this material in the work that I am doing today, or tomorrow". I have trouble seeing the presented material being integrated into my day to day operations.
A. As it said in the first chapter, project managers are in a constant state of chaos. You have the advantage/disadvantage of actually managing projects while you take this course. The quarterback can change signals at the line of scrimmage, but it's tougher to do change them after the ball is snapped. The PM is both changing signals to others while 5 or 6 coaches are calling in plays, while the play is going on. Also, in your[the student's own] organization, many of these items are procedures that you have no choice about. But take interface management for example. If you look at your work task coming up, do you say to yourself about a staff support or functional manager, "Our common boss told them to support me, therefore they must, so I will assume they will be ready when I am." Or do you practice interface management, visit with them, and try to go over what your needs are and make sure they are on your wavelength. If you are like me, I do that with the folks I feel comfortable with, an avoid doing it with folks I am uncomfortable with. (That's stupid Bob, because that means you'll be having problems with people you do not communicate well with, and therefore any problems will be magnified. Yes, I know it is stupid.) This lesson would encourage me to make a chart or list of those interfaces and make it a point to touch bases with each of those interfaces.

Q. I just can't see PMs making the charts. Where I work - the faculty have their lab managers or grad students or someone like me make the charts, and half the time it's the people like me determining who'll do what, with the "PM" making the cursory review before we send it on. I also know that PMs get paid too much to do things like make charts - they make notes and someone interprets their cryptic writing and makes the chart. Sometimes I wish it was made more evident that delegation is a perfectly acceptable thing to do. I have trouble delegating, and I sometimes want someone telling me "You didn't do it yourself. Good job!". But I don't know that this applies to this chapter. I think I'm just whining at you. I see charts like this a lot, and have had to create them, and didn't really have problems with it.
A. The chapter has nice neat graphics, consistent with a textbook in its fourth printing. The point is not the graphics, but the thought process that goes into them. The format really does not matter, it is the thinking behind it.

Q. Less clear to me was Section 5.5, titled "Interface Coordination Through Integration Management." I understand the need to coordinate the activities of multiple departments, however it seemed to turn into a jumbled mess. Figure 5-11 illustrated quite nicely what a jumbled mess it could turn out to be. It seems that in order for a PM to complete a project successfully, that he would need to spend a fair amount of time developing an intimate understanding of the parent organization and departments or functional areas.
A. It seems like a jumbled mess because it usually it. The chart is an attempted to illustrate the interfaces, at least on a work-to-be-done basis. Actual interfaces are colored by politics, money and personality issues, and these are often more important to the success of the project. But charts are a starting place and can help us prioritize our work with those interfaces. As you know, that's where the serious problems lay.

Q. The one question I had also involved the WBS. It is definitely a useful tool for the PM, but my question is how big should the project be before it is worth the effort of making a WBS? I suppose one could argue that it is always worth it, but it seems that it could potentially take too much effort (and hence cost) for a very small project, such as one involving maybe one or two team members.
A. There are always two good questions about any personal endeavor: How much is enough? and How much is too much? In its simplest form, you generally need a cost code to charge your time. That came from a WBS. The detail of the WBS was just "job" or "client." It took little work on your part, except to write the number down. Still, if you are the sole engineer working on a project and want to take a vacation in two months, you might enumerate your tasks for the next two months, estimate your time, determine who else will need to do something in order for you to do what you need to do, and that's your linear responsibility chart. On one sheet of yellow paper.

Q. I thought the chapter had very good use of graphs and tables. Since planning is such a significant part of engineering I think this chapter was very valuable to me. On the flip side it seems like there are a lot of terms used that I have a hard time grasping the full meaning of. I read the chapter and feel like I have a good understanding of the underlying principles but I didn't do well on the quiz because I didn't understand some of the questions clearly. But that is probably due to my lack of mastery of the English language.
A. Your English is fine. Glad you stopped wearing the turban. The chapter tries to formalize and systematize some things that many of use do "on the back of an envelope." Many of the process are highly individualized for different organizations. To me, the most important lesson is that projects should have a planning stage and there are many ways to plan. Remember my 7 P's.

Q. The books states that the three approaches to interface management are insufficient to the tasks. The author prefers the method of Bailetti. What is your suggestion regarding the best approach/combination approach?
A. See the long comment at first of closure module. No one system works, like laws of physics work. They all have some benefit, in that they make the PM think about who's who, who'll do what, when they need to do it.

Q. The author's explanation of cost within systems is very confusing. They say that an added design cost will yield decreased production cost, which will be "traded off" against materials cost. What are they talking about? Are they saying that since production is cheaper, that the money saved in production will be placed into better materials, more materials?
A. What he was saying was that you don't want to spend a lot of money redesigning a component, unless that redesign will increase performance or effectiveness. Individual engineers will sometimes fuss with a detail because it intrigues them, but any of the options for that detail will not change the overall product in a meaningful way. Likewise teams of engineers will fuss with something because they don't want to break up the team and move on to something else. There is a law of diminishing returns with design time for anything.

Q. The muddiest thing in the chapter was the TREND analysis. I just don't understand it
A. The author did not explain it at all, that paragraph is just a reference to another, earlier work that the author must have liked. The following paragraphs illustrate the same notion, though, how to analyze the interface dependencies. In a few weeks we will get into CPM which shows task (work item) dependencies.