ESM 609 Module 05 Closure
Compiled by Greg Kinney
February 25, 2008

QUESTION:
The concept that was most difficult for me to grasp was mixed organizational system.  The idea seems simple enough, part project part functional, but it is difficult for me to conceptualize how that would work.  Sometimes it seems very similar to the matrix organization, but does not function in the same way.  How does one decide if a project should have its own operation or fall under a functional operation?  How does staffing work since a project will likely end, but a functional group will not? Though the concept of combining both organizations is simple, visualizing how it would work is not.

Kinney’s response:
Often the decision about organizational form is made at a higher level than the PM – maybe by the CEO, or at least a task force picked to propose a reorganization.
Mixed organizational form is just that: part of the organization (say a dedicated Projects group) may be completely staffed with technical and project people, and not need to borrow any resources from elsewhere in the company.  This is a Pure Projects group. But then it turns out that two or three big projects must borrow senior engineers from the design engineering group, so they are “matrixed” to Projects, and you end up with a matrix subgroup.  The engineers that remain are in their functional cocoons, and are in a functional organization.  This chaos is what we mean by a mixed organization.

How does one decide if a project should have its own operation or fall within a functional organization?  You could begin by considering what kind of realities you are dealing with – how your larger organization is structured, and what kind of project structure can best be structured.  Then you ask the same questions posed on the top half of p. 199, and make the best recommendation you can as to organizational form.  It may not carry sway with decision makers, but you have made your best case.

How does staffing work since a project will likely end, but a functional group will not?  In this question, you have identified the central problem of a pure project organization.  Once the project ends, you don’t have a home anymore, unless the functional organization is ready and able to take you back, or unless there’s another project to go to.  This type of organization works quite well, really, for those organizations – like building and heavy earthwork contractors – where seasonal, project-specific work is normal and expected.  It doesn’t work as well for professionals who seek some relative stability, and who will often avoid the dilemmas caused by this kind of thing.

COMMENT:
The muddiest thing for me this time was how risk management fits with organization forms.  In general, this is the chapter I have had the most difficulty synthesizing so far.  Perhaps I was more rushed to get through the reading, or perhaps I didn’t devote as much mental energy to the content.  However, I don’t see as much relevance to me here as I had seen in the Project Manager chapter, for example. 

Kinney’s response:
Risk management is a critical aspect of Project Management – probably the most critical, in fact.  The way they worked it into this chapter is really pretty contrived.  They bring it into the topic of project organization by coupling it with the concept of the Project Management Office.  It would be much better to treat it as a chapter.  There are many books written on project risk management; I would probably begin with the PMBOK Guide and go from there.  Let me know if you would like a recommended reading list and I will make one up.

COMMENT:
One student wrote:  The most meaningful section of this module is the section on risk and risk management. Risk management is something that I have been doing intuitively on projects, but I’ve never had a defined process. I would like to take a risk management course if one is offered online or in Anchorage. 

A second student wrote:  The most meaningful thing: risk management. Much of this chapter was reiterations of concepts from “Engineers leading organizations”. Risk management, although I have been introduced to it in the past, is still new to me. This chapter impressed upon me the importance of approaching risk with an ongoing effort, utilizing a dedicated organizational unit, rather than a haphazard and ad-hoc approach. It also enlightened me to the concept of cataloging risk experiences, and using these to make decisions in the future. 

Kinney’s response:
There is a very good course taught by Dr. Jang Ra at UAA entitled “Project Risk Management” and I highly recommend it.  It’s ESM 694 and involves both decision making components and risk management components.  For starters, you may consider also studying the risk management chapters of PMBOK

 

COMMENT:
I felt this chapter was very well organized but if I must find a question… The book talks about risk management being done by a group formed for each project.  I assume that is in an organization without a PMO.  I wonder who gets the final report of the risks and who is responsible.  Must the PM shoulder tracking this as well as all the other work? 

Kinney’s response:
You want the PM involved in risk identification, and the entire risk management process.  He or she needs to understand, and help identify, the dominant risks in a project and to consciously decide what risks warrant formation of contingency plans, what warrant mitigation or workarounds (for example, you can assign your risk by hiring a subcontractor), and what risks to keep a careful watch for.  The PM should track what is going on in his or her project.  As for “creating and maintaining a risk management data bank” – what PMBOK calls a “risk register” – this is a PMO function.

 

COMMENT:
The muddiest item is always the human factors.  I think this is muddy because entire (large) books can be and have been written on it.  They are going at this at such a high level that enough time (so far) hasn’t been spent on this.  How often do you get to choose what organizational form you get to use, anyways? 

Kinney’s response:
Alas, the organizational form is usually either chosen one of two ways: (i) it is consciously chosen at the highest level of the company by executives who don’t tend to interview people like me on the subject; or (ii) it evolves haphazardly in response to events.  The latter is particularly evident in cases where a project must borrow key resources.  Presto!  You now have yourself a matrixed group within the organization.  So the answer is: those of us in the trenches don’t often get to choose.  However, it is in our own best interests to understand the type of organization we work in, and how that compares to other types of organization that could be put into place.  I think we can be more effective if we understand better the strengths and weaknesses of our systems.

 

COMMENT:
One student wrote:  Most meaningful:  I found the section on failure mode and effect analysis interesting. I’ve heard a lot about the different types of organizations before so that part wasn’t new, but I did find this section interesting. As engineers we like to quantify things so I found this to be a slick way of quantifying risk. 

A second student wrote: My question is in regards to risk management.  For the Failure Mode and Effect Analysis (FMEA), what is considered an overly high RPN?  If S, L, and D are at the worst, then the RPN would be 1000.  Would anything over about 500 be considered to high and require attention? Is this number designated by the company or is there a common number.  I was also wondering about the importance of this number.  Would the RPN be a categorization method to decide to go through with a project or would it be as a method to better understand what needs to be prevented?

Kinney’s response:
The book doesn’t present FMEA in a completely accurate context.  The discussion on page 206 seems to indicate FMEA is synonymous with the RPN scoring model.  In reality, FMEA has been around a lot longer than the scoring model.  It is essential a rigorous, even exhaustive approach that identifies what can go wrong with a particular system, item or component; what specific failures are required in order for the wrong outcome to occur; and what likelihood exists that these failures will occur.  It is often accompanied by a fault tree analysis, which uses logic gates, illustrating the safety barriers that must fail in order for the end event to occur.  When you know something about the reliability of these barriers, you can then estimate the probability of the overall failure event.

I have participated in FMEAs but haven’t used the RPN method personally.  I believe that it arose for a good reason: FMEA is good at telling you how failures can occur, and how likely, but it doesn’t give you an overall context, or scale, telling you whether the combination of severity and likelihood (and likelihood of detection) means you need to take action.

The way things like this are applied is to a scale.  A band is established around high risks based on the combination of severity and likelihood.  These require action to prevent (reduce likelihood of) or mitigate (reduce consequences of) the event.  There are some very good references I could point you to on the general approach to risk ranking, but I will point you to one specific web newsletter that is set up to market software for risk banding using the RPN approach:  http://www.reliasoft.com/newsletter/2q2003/rpns.htm This shows the banding approach I’m referring to.  You’ll note that the intro to this newsletter correctly states that the RPN approach is to evaluate the outcomes of FMEA; it doesn’t confuse RPN with FMEA as does our book. 

 

COMMENT:
The muddiest thing I encountered: the project office. I came to understand that this was a place or location from which a project was managed and worked on. I found the writing on this subject vague. Was it a concept? Was it a geographic entity? It was difficult for me to figure this out. In a sense I think the project office is somewhat abstract-both a place and a concept. This was not clarified very well, and thus it was muddy.

Kinney’s response:
I am used to thinking of the project office as the place where your project is headquartered: for example, DOT has offices at many of their major job sites.  The PMO is something different.  I have not worked anywhere that has a true PMO, with a true PMO charter, in the way that the Project Management Institute defines it.  It is an organizational entity built on a concept of bettering project execution.  I am not sure I can improve on the text’s description, which is consistent with what I’ve seen in other accounts.  I know that if I were to take on a project to establish a PMO, the first thing I would want to do is carefully study the experience of other companies – good, bad and ugly – who had done the same.  I’d want to benchmark my approach to those that successfully implemented it.  The critical factor is alluded to by the author in their paragraphs on implementation (p.209): does the organization know what it’s trying to do in setting up a PMO?  If not, then why bother?

COMMENT:
One student wrote:  One thing I found foggy was the figure 4-3 on page 192.  It was difficult to picture how a matrix organizational method would look and seems somewhat complicated.  I will go back and look at this one further.

A second student wrote: The graphic on page 192 of the book showing the matrix style organization was actually kind of confusing. I actually thought that they meant something different in this books definition of matrix organization when I first looked at it. Reading the chapter revealed that they followed the standard meaning, but just had a bad graphic. 

Kinney’s response:
The numbers in the “cells” represent the number of “full-time-equivalent” (FTE) personnel assigned.  For example, for the people from the marketing department, 1.5 FTEs are assigned to the 1st PM, 4 FTEs are assigned to the 2nd PM, and 0.5 are assigned to the 3rd PM.  These three project managers are gobbling up an equivalent of six people from the marketing department.  Note that you might not necessarily have four individual people assigned to PM#2.  Maybe it’s eight people who are giving 20 hours per week to the project.  So I would agree, this is a graphic that has no elegance, but it is, in its own way, meaningful to those of us who work in the bureaucracies.

 

COMMENT:
Muddiest thing in this lesson:  Short section in the textbook on participative management was the muddiest area.  Authors admit that it is an area unto it’s own with much literature to study.  I would like to have seen a more clear/thorough explanation of management by objectives in this module. 

Kinney’s response:
The bible of “management by objectives” is the book that introduced the concept, Peter F. Drucker’s The Practice of Management (1954).  He called it “management by objectives and self-control.” [I haven’t read that book, but I highly, highly recommend his large book Management: Tasks, Responsibilities, Practices which came out 20 years later.]  Animating the concept of MBO is the bromide “you can’t manage what you can’t measure.”  Accordingly, a popular formulation is that for MBO to be effective, objectives must be SMART: specific, measurable, achievable, relevant, and time-specific.

MBO is not as popular as it was in the 1950s and 1960s.  A few of the problems are that it doesn’t capture very well the kind of strategic, poorly definable goals that must propel leading organizations.  Also giving it a bad rap is the fact that whenever metrics are established, it tends to skew organizational effort toward it and away from other important objectives that aren’t specifically laid out.  Worse, there are people in every organization who are masters at gaming the system: they will meet or exceed the goals laid out in the metrics, but they do so at the expense of other objectives or other groups (they “suboptimize”).  In recent years, recognizing the pitfalls but also the promise of MBO, we have seen the emergence of “The Balanced Scorecard” approach, which attempts to manage broad objectives in a balanced way.  The business section at Barnes and Noble will give you a lot of information on all of this.

 

COMMENT:
The muddiest was in regards to the organization of projects.  This is probably due to the structure I currently work in.  These aren’t concepts I usually am faced with at work.  We work in a matrix organization so that section was very clear.  The other sections were less obvious and usually are handled at a higher level at my office. 

Kinney’s response:
This is usually hard to understand unless you’ve lived through the particular organization type in question.  I’ve lived through functional, team-based and matrix organizations, which is easy to understand in the multifunctional environment involving geographically divided operations groups, centralized or semicentralized support functions (such as accounting, engineering, etc.), and central Projects.  I personally have never lived through a Pure Projects organization, and suspect that this really is only achievable in an organization that does mostly big projects (Fluor, Parsons, Jacobs and Bechtel are all in this niche).  That one is easy to understand for me: you work directly for one PM on whatever projects he or she is managing until the work runs out, and then you either get reassigned or let go.  Come to think of it, I have worked in that kind of job, back when I worked construction projects.  It’s normal when you’re one of the hands.

 

COMMENTS