Module 6 closure
Spring 2006
Prepared by Greg Kinney

MUDDIEST ITEMS
Q: "The muddiest" was the use of an action plan and WBS.  I understand that planning of a project can be done in various ways, but I do not see the books use of dividing it up in both action plan and WBS, for me it looks like that these to plans can be done in one bigger plan.
A:  This will come clearer a little later as you work on WBS structures.  The WBS is the most detailed breakdown of what needs to be done.  Done correctly, it is a good control tool.  However, its relationship to the action plan is a little like the relationship of functionally coded computer programming lines to the flowchart.  If you look at the flowchart, it’s a lot more comprehensible than the lines of code, which is why you need the flowchart done first in most cases.  Action plans usually precede the WBS for the same reason.  Even if not done first, it should be done anyway, so that people can see in plain language what the plan of action is.  Yes, there is some level of redundancy, but action plans and work breakdown structures are actually complementary.

Q:  Along the lines of the material review question 12, it seems to me like the WBS can be tailored for the use as a Project Plan or an Action Plan. I tried to answer the question as if there is a difference since the author broke them into different discussions. However, if there is a difference, the difference seems to be in the functional purpose therefore a different name for the same thing, a WBS. 
A:  The differences between a WBS and an action plan will come clearer a little later as you work on WBS structures.  The WBS is the most detailed breakdown of what needs to be done.  Done correctly, it is a good control tool.  However, its relationship to the action plan is a little like the relationship of functionally coded computer programming lines to the flowchart.  If you look at the flowchart, it’s a lot more comprehensible than the lines of code, which is why you need the flowchart done first in most cases.  Action plans usually precede the WBS for the same reason.  Even if not done first, it should be done anyway, so that people can see in plain language what the plan of action is.  Yes, there is some level of redundancy, but action plans and work breakdown structures are actually complementary. 
As for the overall project plan, it is the complete set of documents used to describe project objectives, methods, schedules and budgets, and is the most comprehensive overall look at what the project consists of.  The action plan and WBS are part of the project plan, but address only actions required to assemble and implement the project. 

Q:  The interface coordination through integration management is the most unclear to me. I’ve got so much knowledge and keep referring to my knowledge of project management in construction and environmental projects. Integration management is much more complex coordinating many multi-disciplinary teams simultaneously, whereas in the project management I am familiar with, uses one multi-disciplinary team to create a project. 
A:  Good points.  I believe the integration management challenge is most acute in large organizations and large projects involving lots of disciplines, especially where consumer or user feedback is critical.  For smaller projects, though seldom easy, it is at least easier to get a handle on successful project creation and implementation.  The most challenging jobs that I’ve been part of involve engineering to satisfy operational end uses, in which operations must be deeply involved in the development of the product and the finish O&M documentation, and in which stakeholders (regulatory agencies and owners) also exert pressure.  I have yet to find a magic solution to this.  You have to work in detail, and to a definite plan, but at the same time you have to do lots of coordination and be somewhat open during development of the project.  It’s not easy to reconcile those goals.

Q:  The end of chapter five was [not as] clear to me [as other parts of the chapter].  In particular, the section that dealt with interface coordination and integration management was not explained as well.  For example, multidisciplinary teams (MTs) were mentioned several times throughout the latter part of the chapter.  I wasn’t sure if they were beneficial because the text went both ways concerning their involvement in the process of integration.  The application of TREND to the structuring of MTs was still fuzzy even when I got to the end of the chapter.  I didn’t feel that I really grasped what the authors were trying to convey in regards to MTs and their relationship to TREND.  I understand that TREND helps to map out the interdependencies within the firm but the details surrounding the actual mapping (logic) was brief.  The section finished in an open ended manner.  One of the paragraphs stated, “… but they do not reflect the uncertainty associated with tasks on large, complex project.”  What is used in that case?  Do they couple this concept with risk management principles?
A:  The discussion of TREND came up in the previous Module 05 closure.  I personally am not familiar with this methodology, and the authors do little more than make both of us aware it exists.  (I can find a few references in a Google search, but it would take a real hunt to get there.)  I agree with Dr. Perkins that this has hints of the management-fad phenomenon and that the example comes up without much explanation.  To quote him:  “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.”
Now to the quote -  I’ll give the complete quote (p. 264):  “The logic of [Bailetti’s] approach to structuring MT is strong.  The WBS and linear responsibility charts are a good initial source of information on interfaces, but they do not reflect the uncertainty associated with tasks on large, complex projects.  Further, they implicitly assume that interfaces are stable within and across project phases – an assumption often contrary to fact.”  They are suggesting that a clearer delineation of interfaces is appropriate to raising management awareness of critical interdependencies.  Looking at Figure 5-11, which is an interface map, you see a graphical map of functions and exactly how the outputs of one group are critical to someone else.  The WBS doesn’t show this directly, it just shows what resources are applied to the project in what sequence, and what must be completed before or after.  The linear responsibility chart comes closer to illustrating interdependencies, but it is structured in terms of task responsibilities, and doesn’t fully illustrate the interfaces.  Bailetti’s diagram helps bring these to the surface, and therefore helps show how groups can affect one another – which is helpful in risk management.

Q:  I have not been exposed to many interface maps in projects I have been involved with. Why haven’t more organizations adopted the use of these interface charts to show interdependencies between owner, representative, designer, contractors and subs?  
A:  In my experience, I’ve seen a number of linear responsibility charts put together.  Visio has a useful work process application standard that facilitates this.  I agree with the authors that the kind of chart illustrated in Figure 5-11 is a more powerful representation of interfaces.  Why isn’t this used more?  Partly it’s a shortcoming of the education and training system in seeing the use of the approach and incorporating it in the curriculum.  And if it’s not included in the textbooks, the practitioners aren’t going to know it’s there.  I’ve looked at a lot of project management books and this is the first time I’ve seen Bailetti’s interface map.  The other part of the problem is that organizations in general are full of people who aren’t incentivized to try new approaches, and in fact are more likely to be ridiculed for trying.  That is to say, even if you know about interface mapping (unlikely enough), you aren’t necessarily encouraged to go beyond your standard Microsoft Project GANTT charts and attempt it.  It’s difficult to do correctly and you stand a chance of getting slammed if you try (people will question the value of what you’ve done, etc.).
That doesn’t mean you shouldn’t do it; as practitioners, we need to show creativity and some courage, and eventually I believe we will be recognized for doing so.  I’m just saying that organizations have inertia and are often set in their ways, so are slow to embrace new tools.  That is, until a rare opportunity arises to clearly show the value of a new approach.

Q:  The lack of “hands on” work with all concepts and theories involved is what makes this chapter muddy. I understand it cannot be done in 30 pages and that it probably takes work experience to get familiar with it. Another thing that I am missing in chapter is how planning can be misused to blame others. This is mentioned in the old closure but I would like the topic to be investigated further. I am novice in ethics of the planning process. 
A:  Yes, this is hard to cover in 30 pages.  It is one of those things that becomes more meaningful as you proceed in your career and experience both success and failure in planning and execution of projects.  On the misuse of planning, I too read the passage in the old closure, which came in the form of a question from someone obviously experienced in it.  What I think this person referred to is the fact that plans are often put together unrealistically.  If project success is defined as meeting scope, schedule and budget in a manner acceptable to the customer, you have a large bundle of constraints therein!  What happens too often in the planning process is that people will aim high on scope and low on schedule and budget.  Overbearing managers and executives may then insist that the scope will be done within the schedule and budget allotted, because they say so.  But saying it doesn’t make it so, and the planner often knows that it can’t be done that quickly or that cheaply.  That forces the planner, or the planning organization, to create defenses (known in the vernacular as “CYA” standing for you-know-what).  They’ll adopt contingencies and may try to create mechanisms to assure they won’t be blamed for the failure.  I’m afraid that all of this falls more appropriately into the category of office politics rather than good project planning, but it’s all part of the landscape we inhabit when we get into projects.

 

Q:  Consider a weak matrix organization. What do you do when you need resources existing in another functional department? Resources that were agreed on (in the project schedule) to be available, at a certain point in time.

1 ) Contact the other department in forehand and negotiate. Motivate it is needed in the project.
2 ) Tell your boss that you are having problems with getting access to the resources.
3 ) Three possible outcomes.
            A ) The boss helps you out. You are good.
            B ) The boss tries to help you out but runs into the same problem as you, but at a higher level.
C ) The boss tells you “Give me a break. We don’t need any kind of trouble like this now. This is a simple issue that you have to handle your own.”

What is the solution for case B and C, and how should the solution be motivation to make a strong impression?
A:  There’s often not a good solution for this situation, which shows the weakness of project managers having responsibility but no line authority over staffers.  Here are my thoughts on it.  Project managers are largely paid to be persuasive, and that often means being a little pushy if your initial try at negotiation won’t work.  In practice, you need to make clear the consequences of not getting your needed resources and frame it up in a way that makes the functional managers responsible for their choices and priorities.  As project manager, you may need to move the dialog upstairs to the boss’ boss.  In all cases, you need to honestly present all the alternatives, including getting external resources (who probably aren’t as qualified due to lack of familiarity with the system), as well as deferral of the project and let the responsible manager make the decisions, which you will then need to document.

Q:  I had trouble with this portion of the book.  Whether it was the lay out of the chapter or the author, I had trouble keeping focused on the information and absorbing it all.   The information seemed cobbled together and ‘muddy’.   Even after I reread many portions I was unable to answer most of the quiz and homework questions without much searching. 
A:  Looking over the old closure notes, I see that Dr. Perkins had a number of similar comments on this chapter.  Overall, I agree with his perspective that the authors did not do a bad job on this, although this is not the crown jewel of the book either. 

 

CLEAREST ITEMS