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.
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.
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
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:
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
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
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:
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.
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.