Module 06 Spring 2008 Closure
Posted by Greg Kinney
March 6, 2008

Q:  The muddy part for this chapter has to do with risk management planning.  The authors have multiple times mentioned that companies do not want to plan ahead (as mentioned on the first page of the chapter) and that they do not like listing risks because it is too negative.  This seems like a bad idea to me, but has it worked for any company that you know of?
A:  I am not sure that they don’t want to plan ahead, but they often don’t.  Some businesses don’t really implement forward planning, because they tend to be very short term focused.  Longer term planning, of the type that project managers specialize in, is foreign to some business and operations oriented people who want results now.  Often they have a hard time understanding, or simply don’t want to hear, why things take as long as they do. 
For these folks, they often have what they think of as a “plan,” but it’s something like vaguely stated New Year’s Resolutions – in other words, they may have a line item describing what they want, but there is nothing substantive underneath that line item describing how it is to be done.
Systematic planning is time consuming and hard, boring work.  It is therefore counter to the nature of many operations oriented, “results now” companies.  I agree with the authors – and disagree very strongly with Tom Peters, whose glib but popular business advice has often been destructive, when he advocates “ready, fire, aim” as a sound approach.  It hasn’t been good anywhere I’ve worked.
In terms of listing risks, it requires discipline to list specifically what the risks are and to list what action needs to be taken to appropriately and effectively manage the risks.  I believe that risk identification and contingency planning is an important part of project planning.  If I were to have to evaluate it, I would say it is less important overall than general project execution planning, because the risks vastly increase if you don’t plan and execute well.

Q:  The concept that was most difficult for me to grasp was integration management.  I do most of my work under a multi-disciplinary team, but the text made it seem much more complicated than it actually feels.  Maybe this is my naiveté at project management, but most of our work is performed under these MTs, so it seems like a natural state of collaboration.  The reading discusses conflict and difficulty with interdependency, but these problems seem to be resolved fairly simply with just a little discussion.  The TREND concept just seemed over the top for smaller projects and over simplified for substantial projects. 
A:  There is really not enough information in the chapter to give us much insight into the TREND approach itself, or to how it is applied, or to evaluate its complications.  The authors give barely enough to whet our appetite if we wish to investigate further.  They do hint that the approach may be outmoded now, but we’re left to imagine that it may have been the basis for further refinements later.  In any event, from what I read, this would be over the top for smaller projects.  But for big projects, I could see tremendous benefits.  Think about the interfaces that must be figured out in a car project between the designers and the subassembly engineering groups.  Think also about what is called “configuration management”: you need to figure out, catalog and document all the parts of all the assemblies in a hierarchical manner.  This requires lots of engineering coordination, lots of vendor coordination, and so on.

Q:  I think the muddiest section of the module is the section on systems integration. I’ve read it several times and am still confused. Is it only applicable to computer software development? Would it be the same on a multi-discipline engineering project? I did structural engineering and it would never have occurred to me to take off on my own without considering the input of the other disciplines. 
A:         It certainly wouldn’t be applicable only to software.  Think about aircraft systems, particularly military systems.  These are equipped with multiple systems that must be interfaced in various ways. 
Since I have done both structural and mechanical engineering work, I share your amazement that anyone would not coordinate with other disciplines.  And most people would agree.  Yet, despite our best intentions, we very often fail to assure that our plans talk to one another, even though our work is much simpler than the systems I mentioned above.  Where it fails, in my experience, is that either we engineers or our designers have to create a first stab at something, and we evolve it, and don’t necessarily realize that our electrical designers are doing a slightly different variation on the same thing.  We’re juggling different projects and lots of different drawings, and we miss it during design.  But construction is a truth serum; if we missed a problem in design, we are sure to deal with it in construction support.  I certainly don’t see that the very elaborate systems integration tools discussed by the authors would be appropriate to the projects we typically do.  However, we all have challenges with it.

Q:        One thing I found foggy was that if the PM looks at the linear responsibility chart and sees potential conflict among several parties (client, functional areas, managers, etc..)  in what ways might a PM be proactive in mitigating against the conflict?  (I know communication is vital, but are there any other suggestions or practices that have been successful?)
A:         In the first place, for each of the line items in the linear responsibility chart, there should be only one 1 [actual responsibility] and one 2 [general supervision] and one 6 [final approval].  This clarifies who is in charge at what stage and who will be doing the work.  Where it gets muddy is that you can have multiple parties at level 3 [must be consulted], 4 [may be consulted] and 5 [must be notified].  And really, the biggest problem is at level 3, because multiple parties that must be consulted may well have opposing views.
What ultimately helps is having the clear authority laid out so that some authority acts as the tie-breaker.  Apart from that, it is wise to bring forth all the issues and problems as quickly as possible, and to confront them productively.  The PM may end up being a negotiator in the event of conflict, trying to “invent options for mutual gain” [quoting from Fischer and Ury’s Getting to Yes].   

Q: Muddiest:  In multifunctional teams does the PM still keep the ball rolling?  It sounded like multifunctional teams were just the grouping of a project team so that all disciplines were represented.  But in other sections of the chapter the multifunctional team seemed to share authority and decision making more equally than if a PM was in charge of the group.
A:  The Project Manager’s job is to keep the ball rolling whether multifunctional teams are used or anything else is used.  The structure of teams will certainly influence the chain of command that the PM will have to work through, but the PM will still need to exert his influence to assure that the teams are productive, that they get their work done on time and on schedule for the benefit of the project.

Q:  Muddiest:   What I found as the muddiest topic in this chapter was when you need all this paperwork and when you don’t.  Not everything is this huge project (thank goodness), and some of this paperwork isn’t always needed.  However, how do you decide how much is needed?  A Work Breakdown Structure of some sort is almost always needed, but how much detail is needed for the master planning schedule? 
A:  I have to answer in generalities:  it varies according to the complexity of the project.  For small projects (a/k/a minor modifications), you want to have an action plan.  There definitely needs to be a specific set of instructions and engineered plans.  But there is little return on investment if you develop a large WBS for minor work. 

Q: This whole chapter was pretty muddy as compared to the previous reading…  The most clear item was the concept of the WBS.  Mind you, I don’t see things working out this simply in real life, but I agree that having a very detailed & structured plan is important to get things rolling and prevent any forthcoming disasters.  I think the reading was not as supportive in this chapter of the questions asked.  In previous chapters the questions asked had a fairly definite answer provided within the reading, and usually outlined in the summary.  I did not find this to be the case with Ch5 and am not having good feelings about my semi intuitive answers to the HW questions. 
A:  This set of questions required that you reach a little into your own experience base to answer them, as you did.  It’s great to see how many ways the students answered the questions.

Q:  Clearest thing in this module:  work breakdown structure and linear responsibility charts.  I work with these quite a bit and there was some very good examples of different types that I found will be helpful to me.  I also really like the opening sentence to the chapter in the text that reads, “Plans are only good intentions unless they immediately degenerate into hard work” (Peter Drucker).  I can see this quote making its way to a list of ones that I repeat frequently. 
A:  Drucker died in November 2005 just a few days short of his 96th birthday.  He was really one of the greats.  I can highly recommend his books for a completely refreshing perspective that has never gone out of style, even though the companies he described may have fallen (usually because they lost their way and wouldn’t follow his advice).

Q:  Muddiest thing in this module:  I’m almost entirely in the design and construction project management area and so the discussions about systems integration and management by phase gates was less familiar to me than other parts of the module.  For example, figure 5-11 gives me a mild headache when I look at it and trying to make sense of it.
A:  To me, figure 5-11 is good at addressing the very special circumstances that exist at a high technology manufacturing firm.  To preserve market share, these companies have to implement continuous improvement and, at times, quantum improvement.  So they always have to have projects in the pipeline to deliver their next product ahead of the competition.  This means that they must tightly integrate project planning with feedback from engineers and operations on what’s working and what’s not.  They are using their specialized knowledge to feed back into the projects arena in a relatively seamless way.  Those of us in more traditional settings don’t have the same level of project interface requirements.

Q:  I understand conceptually what the difference is between the WBS and the Action Plan; however, graphically they look very similar.  This was the muddiest part for me.  Ultimately, as long as you understand what the tools are and how to use them this seems most important. 
A:  Well, the action plan is a little bit like a glorified list of steps.  The WBS is a roll-up of all the steps, and if it gets detailed, the action plan is decomposed into lots of details.

Q:  I found it interesting learning about the different planning methods.  In chapter 4, some of this was touched on or hinted, but was more fully explained by this chapter.  I can see why the authors organized the book this way (discussing the company organization and then going into more detail with the project), but I almost think that it would make more sense discussing the subjects in the opposite order.  This would emphasize the need for a matrix organization with the functional groups input in the project planning. 
A:  I know from painful experience, including on something major I’m doing right now, that getting a smooth-flowing outline that works really well is a very hard thing to do.  The authors have a challenge on putting together something so broad.  So, while I agree that some elements of their flow is sometimes less than optimal, it’s something else to come up with something better.

COMMENTS

• After completing the reading, I found the section on project plan elements to be the most interesting.  I enjoyed the way that is provided a general outline for project considerations.  I have been involved in the more specific levels of project planning before, but have not spent much time working at this most basic level.  I though this provided a good starting point and ideas for consideration.  I especially enjoyed the risk management plans section.  I think this is a very valuable component that often gets overlooked or is performed in more of a “check-the-box” way.  These plans are required at my company, but are sometimes not shared with the project team.  I think the plans are an excellent tool for minimizing risk if everyone is aware of the plan.
• The best part of this module was figuring out what my work calls the different stages of planning discussed in the text.  For example, we call the postplanning review a “readiness review” but it is basically someone experienced who is not involved in the project asking a list of detailed questions to make sure everything is in place for proper execution of the work.  It is good to see that my work participates in many of the techniques given in the text.  However, I’m not sure we have anything equivalent to the WBS process.  Although, it seems like a WBS is almost intuitive- I understand that there are many ways a WBS can go wrong (not getting down to equivalent levels of detail), but it also seems like one would have to attack a project by tackling small piece by small piece whether you wrote them out first or not.
• One thing I found interesting was the organization of various plans (project plans, action plans, and WBS) and how they create clear structure to the project.  I have been in the consulting field for 4 years and have been asked to create similar plans but with no clear explanation of how they are to be used.  This part was very helpful.
• Clearest:  I liked the imagery of the “even planning process” being like a sketch of the face.  It reminded me of when you have to tighten screws in a pattern so that one side is not done before the other.  Drawing the broad strokes of the overall project and then filling in details, one level at a time, makes sense.  You cannot fill in one task in great detail and leave other information in draft form.  You must endeavor to give careful thought to all areas, and seek knowledgeable help when it is not your area of expertise.
• Most useful thing learned: The project plan components and elements were of interesting note.  Upon reviewing some of the “project” documents that my organization has I found quite a number of the elements missing from most of the projects (and they should probably be there).  That should provide hours of entertainment at work going back over the existing project structure and documentation to fill in the gaps.  (For most of the projects about the only items really defined are the overview and the objective.) 
• Muddiest item: The muddiest item that I found in the module 5 information was the description of the work breakdown structure.  The amount of information contained is significant and there seems to be no defined way of what really is required to be present.  I understand that it ties a lot of the individual documents together into a coherent whole, but it seems like one could easily get bogged down in the paperwork, especially getting all the pieces together for the WBS.  I did like how the authors presented a kind of step by step building guide for a WBS.  It was interesting how they provided a breakdown of each component so the current step of the WBS generation would have the requisite prior pieces in place.  That kind of provided a logical roadmap for putting together a WBS without having to backtrack to complete a necessary portion that was overlooked up until then. 
• The work breakdown structure combined shown on page 258 was helpful. It clearly shows the chain of concern for decisions on specific matters and who should be involved in decisions related to each subtask. The chart on page 259, the simplified linear responsibility chart was actually way muddier and less easy to understand. Perhaps it was the use of symbols in the first chart, but I found it much easier to determine when a particular individual must give approval from that chart than the second one. Overall, this chapter was quite clear and concise and there wasn’t too much that was muddy. Determining what all of the different charts and structures were based on their names and keeping them straight was about as difficult as it got. Remembering which chart was the Gozinto chart for instance.