The last chapter took us to the point of starting a project. This one takes us to concerns that apply to running a project. We assume that we have decided that a project is needed, and will take place. Now, we need to plan what we will do in it.
Let's skip the part about convincing ourselves that we need a plan, and start with the Project Plan Contents on page 279.
The text catches its breath for a moment, then adds five more items that should be in a project plan.
The text also spends a few paragraphs on work packages, but it has already told us twice to define the work that
will be done in the project. There is also a list of activities which
provide opportunities for adverse effects on the project, but they have
all been mentioned above, so let's move ahead.
On page 287, the text introduces project priorities. It introduces the subject with two anecdotes about people who have too much to do, and no guidance about which things are the important ones. It may well be, as in the second example, that the manager has no more idea about priorities than the workers themselves. In that case, how can we set priorities? The text suggests on page 289 that we could assign priority (or urgency) based on the contribution the project or task will make to the organization's goals. This list of goals shows we can think or more than money"
The text proposes that if no system of prioritization is used, then staff will make their own choices. Four kinds of choices are suggested, none of which fit the reasons above:
While each of the factors above is a motivational factor for
staff, those factors should be mentioned as inducements to accept
assignments, not as reasons to prioritize them.
On page 290, the text offers a set of phrases that describe the urgency of a project. Several phrases are grouped as priority 1, several as priority 2, and a few are marked as priority 3. The more urgent the phrasing, the higher the priority. The trick is to determine whether something is needed, needed quickly, or needed soonest/earliest.
Whether your company uses this system or another one, the text recommends using one to allow requests to be rated on a common scale and measured in the same way.
On page 293, we turn to project scheduling. The text recommends using graphic scheduling tools that show phases, durations, dependencies, and milestones. In programs that create such plans, you will probably also have the ability to assign resources to tasks, which helps to track their availability for other tasks.
Page 298 takes us to monitoring, evaluation, and control. The text presents a graphic on page 299 that shows a circle marked with four actions:
This strikes me as being very similar to Dr. Deming's cycle of Plan -> Do -> Check -> Act. The cycle in the text simply takes the point of view of a manager instead of that of a participant.
We are shown a long list of things that need standards. We are reminded that we have to watch performance or get reports on it, and we should watch for trouble in that data. We must analyze the data we collect. We must finally take action where it is required to improve performance on the project.
The text mentions that the actions above can take place as part of an audit of a project. We should pay attention to its observation that we can find things that are going well, as well as finding problems. Whichever we find, we should take the opportunity to share information and plan for improvement in all areas of the project.
On page 304, we turn to risk management. You may have encountered discussions of risk in other texts. This one follows the usual pattern, but has two new ideas:
On page 310, the text begins a section on auditing, which it has already mentioned. Most people will not associate the word audit with good feelings, but the text reminds us that we should be checking the performance of a progress at all times, and an audit is just a formal check.
The text lists seven kinds of audits, classified by their area of interest:
The text makes a point of explaining that audit teams for projects have a logical problem. An internal
project audit team is composed of staff from the project, who will be
familiar with the project, but who will not be working on the project
while they are conducting the audit. An external
project audit team is composed of staff from outside the project, so
their work on the audit will not detract from progress in the project
itself, but their lack of familiarity with the project may. The text
recommends using a composite
project audit team, composed of staff from the project and from other
sources, for the best balance in conducting the audit and progressing
with the project.
The next major topic is scheduling standards, which starts on page 316. The text explains that scheduling standards are the rules that are used when creating and maintaining the schedules
for the project, which sounds pretty dull. It helps to have such
standards because they provide common themes in the project documents.
They allow the project staff to have expectations about such documents
that will provide reference points from one document to another.
The text presents eighteen topics that relate to common features in schedules. They range from labeling standards to rules about the kinds of tasks we will have and how tasks are displayed and completed. Some are advisory, and some are much more involved instructions about creating schedules.
For several pages, the text discusses outsourcing project management, which seems strange, since the approach of the entire book has been about doing project management for other companies. That would make us the outsource, wouldn't it? This section seems less useful than some of the others, so we will move on again.
To fill up three pages, the text repeats its recommendation that we should
choose a Project Management System,
such as Microsoft Project, to create the schedules
and plans for our projects. It
talks about subsystems in such software, but the point of this section
is obscured by the language the author uses. It you are reading this section,
get up, walk around, move your arms, and breathe deeply. Coffee can be
It should be more useful to think about costs for a few minutes. On page 334, the text presents a list of common project costs (which continues on the next page):
The text continues to discuss other sources of costs that should be considered, such as an add-on cost for profit. These items belong in an accounting discussion more than a project management text, so we will move on again.
On page 338, the text introduces the Work Breakdown Structure (WBS), which is simply a diagram of the parts of a project. It can resemble an organization chart, but the entity being described is your project, not an organization. As the text explains, a WBS can be used as a tool to break the project into work packages, which contain the work units that will be assigned in the project. The examples at this web site show us some variations in the way a WBS can be displayed. Note that we are told that the Tree Structure view is the most popular. In the examples shown, I think it may be the least readable.
The last topic in the chapter is earned value management. It is
a system of measuring how well a project is complying with its initial
plan. This seems like a laudable goal, but it strikes me as being too
rigid to be of much use. I will suggest that we leave it behind by quoting
Moltke's first aphorism: "No plan of battle ever survives
first contact with the enemy." If we do not recognize that all plans
must change over time, we are doomed to failure.