PPM 301 - Project Management

Section 2. Project Organizational Design

Objectives:

This lesson discusses aspects of project management relating to interfacing with the customer's organization. Objectives important to this lesson:

1. Organizing for project management
   
2. Project organization charting
   
3. Authority-responsibility-accountability
4. Project management training
5. Working in projects
6. Project office
   

Concepts:

The chapter begins with some observations about traditional organizational hierarchies being unsuited to project management. However the customer's organization is structured, it is probably not useful for the reordering activities of projects that bring large changes to that organization. Starting on page 58, we see several scenarios that might be used in project organization.

• project organization - staff are taken from all areas of the organization to work on the project
  
• functional organization - project staff are assigned to work with functional areas of the organization and project coordination runs through functional managers and their superiors
• functional matrix - a project manager is given full authority to run the project through all functional areas of the organization
• balanced matrix - a project manager shares authority and responsibility with functional managers
• traditional matrix - a project manager and functional managers are given complementary authority for the project
  

The text goes on at length about methods of under which authority and responsibility can be spread through an organization and a project team. This is a distraction from the fact that a customer may have unique requirements that will not fit any model in a textbook. It is more useful to remember that you need to have a clear idea of who will make decisions and who will carry them out.

Let's move ahead to the Roles of the Project Manager on page 61.

• a strategist who plans the use of project resources
• a negotiator who obtains resources when more are needed
• an organizer who directs the actions of the project team
• a leader of the staff who perform oversight of the project
• a mentor for less experienced members of the team
• a motivator for the team, who creates an environment that enhances performance
• a controller who monitors the performance of the resources of the project
• a diplomat who maintains working relationships with the project stakeholders
  

It seems that we require the project manager to be many things to many people. In fact, not every project manager will excel in all of these roles. If you are not skilled in one or more roles, this means that you need to delegate that role to staff who are skilled in it, or you have a problem. As as exercise, relate the roles of a project manager to the measures of success and failure from chapter 1. Consider how a lack of skill in each area puts specific measures of success at risk, or makes measures of failure more likely. This is assignment 1 for this chapter.

On page 63, the text described, without examples, how a typical organization chart fails to describe the interactions that usually exist between employees, inside work groups and across work groups. The authors require us to trust them in this regard. They are correct. In my experience, a formal organization chart is often out of date, and does not reflect the interactions between teams and individuals, or the special duties of most individuals. For many years, my job description, regardless of my actual job, ended with a single phrase: "and other duties as assigned by the director". It was meant to be a catch all category that reflected the reality of changing and emergent needs.

The text describes a new tool, the Linear Responsibility Chart (LRC). The purpose of the tool is not clear from the description in the text, nor is it clear from the first example. Look at the example on page 65. In the first column of a standard spreadsheet we see a list of activities. The text calls these work units. These activities are parts of the project. In the first row of the spreadsheet, in columns 2, 3, 4, and 5, we see the names of several job titles from the organization chart. (The LRC could have used actual names in these columns instead of job titles.) In the cells where these rows and columns intersect, we see numbers that correspond to a legend at the bottom of the chart. In this case, each job title has been assigned a role with regard to each work unit, which is what the LRC is all about. Six roles are used in this example:

1. Actual responsibility - this person is supposed to do the work
2. General supervision - this person is in charge of getting the work done
3. Must be consulted - this person is probably a subject matter expert regarding this work unit
4. May be consulted - this person knows something about the work unit, but work can continue if they are not consulted
5. Must be notified - this person must receive reports about this work unit
6. Approval authority - this person has authority to approve the work that is submitted
   

As you can see, the LRC is not only a list of things to be done for the project, It is also a list of who does, manages, approves, and has input on those things. The example in the text has an entry on every cell in the table, but this will not be true in larger organizations. In meetings I attended this week, I saw some charts of this type that were referred to as RACI charts. They were certainly LRC charts as well, but they focused on four assignable roles: Responsible, Accountable, Consult, and Inform. You might consider the RACI chart to be a short form of the LRC chart. If you follow the link above, you will see many other acronyms for this kind of chart that vary only slightly from each other. The LRC form may be the most flexible, since it does not presume roles that may not apply to your project.

Form a group to do this assignment. Assume you are going to work on a project. Pick a topic for the project and assign at least five named work units to the people in your group in an LRC chart. (Hint: use Excel to make the chart.) Use a numeric code, like the six point code in my notes to assign activities to various people for each task. Make sure to assign something to each team member, but do not assign all team members to all work units. Make sure each work unit has a responsible party, a supervisor, someone who must be notified, and an approver. If you do not have at least five members in your group, make up some imaginary team members. This will be assignment 2 for this chapter.

The text changes topics on page 66 to talk about Authority-Responsibility-Accountability. At first, it defines only the first one, explaining that the authority to act about something can come in two types. Actual legal authority is called de jure authority. Authority that comes from knowledge and experience is called de facto authority. Often, the people who know the most about a situation or process are the ones who use it, not the ones who are in charge of it. A project manager needs to work with both kinds of authorities. To build a system that will work, we need input and approval from de facto authorities. To gain enterprise acceptance for the system, we need to please the de jure authorities.

The text attempts to define responsibility, but does so only in the context of a project. Responsibility is being answerable for something, which means that you are the person who is supposed to do something or you are managing the staff who are supposed to do it. It could also mean that you are the person who approves, allows, and oversees the use or performance of something. The use of the word ""answerable" implies a penalty for failure or misuse of the resource for which you are responsible. This takes us to the third word, accountability, which the text defines as the state of assuming liability for something of value (page 69). In the context of this discussion, there is certainly an overlap from responsibility to accountability. We might say that responsibility is about doing something right, and accountability is about accepting the blame if it is done wrong. We should also presume that blame takes us nowhere, so it should only be a flag to tell us to go back and make things right.

The text discusses training for four types of people involved in projects. The table on page 72 gives us the differences between the four roles:

• senior leaders - people who develop the strategic vision and goals of the project; these people provide direction for a project
  
• manager of project leaders - people who obtain and allocate resources to project teams;  these people plan the work of the teams
  
• project leaders - people in charge of individual project teams; these people manage the work done by teams
  
• project team members - people who work on a project team; these people do the work assigned to the teams
  

The text continues with a vague description of the kind of training needed by a person in each of those roles. It may be assumed that staff who do project management for a living might already have such training, but that staff assigned to a project from a customer's organization may not have had it. This is a tricky decision to make. People who have never worked on a project will need to know something about how to do so. However, nothing inspires mutiny against a project quite like sending people to training that they have already had, with the possible exception of doing it multiple times.

The text assumes that a project team member may need four days of training in project work. This seems a bit much when we consider the list of things a project member must understand on page 75.

• Time, Cost, and Quality - There is an old saying that you can have something cheap, fast, or good, but you can't have more than two of those things at once. If you want it cheap and fast, the quality will suffer. If you want it cheap and good, it will take longer to do it. If you want it fast and good, it will cost more to do it. This is the version that our authors seem to accept. They recommend that we first seek to bring the project in on time. They recommend that we next seek to do the project well, and that we consider the cost of the project as the least important of the three parameters.
• Skills available may not match skills assigned - The project may need staff with skils that our staff do not have. This is a common source of cost creep (increase in cost) due to having to seek out and employ specialists for the project.
• Projects are temporary - This is a bit specious, but the point is that projects have a beginning and an end. If there is no end projected, it is not a project and may be business as usual. The point for a project member is that they will only be on the project until it is done or they are done with their part of it.
• Work assignments must be understood - How can you do a job if you don't understand that job? Project team member must be given work assignments so that they understand what to do to complete them.
• Participate in planning - Each person on a project should be part of the planning that concerns things done at their level. People need to understand how much time they have to do something in order to meet deadlines for their work. They need to know what resources are being allocated for a task, and when that allocation ends.
  
• Report progress - Projects are also about monitoring what happens, so team members should accept the idea of doing regular reports about their work.
  

The authors end the chapter with a discussion of having an arm of your organization dedicated to running projects. They call it a Project Office, and suggest on page 80 that it may be called by any of several other names. There is a list of functions such an office might provide to a company on pages 81 and 82. Items in this list might be done for any project we might imagine. The point of having a project office might be that we want to standardize our project methods from one project to another. It might also be that we want to have some of the same staff work on each project, which would allow them to gain a better view of the big picture for our company.

A small company that does very few projects might see no value in a project office. Any company that conducts projects regularly, however, might get value from a project office right away.