Page 76 -

other project schedules. Allocation reports can be run to verify that no resource is over- or
under-allocated. Alternately, multiple projects can be included on a single schedule. This
is slightly harder to maintain, but very easy to understand at a glance.
Another common way for two projects to be interdependent is when one project has a
task that has a predecessor in another project. Identifying these predecessors is generally
straightforward. Any time a task relies on a piece of software, a document, or another
work product that is scheduled to be built in another project, a dependency is created in
the schedule. The easiest way to handle this situation is to require that the dependent task
does not begin until its predecessor ends. Modern project management software tools
have features that help to automate this process by grouping multiple projects together
into one master schedule.
The one important pitfall is that each cross-project dependency increases the risk of delay
on the dependent project. To mitigate this risk, every predecessor must be reviewed at the
project meetings for the dependent project.
Prioritize Projects Realistically
Prioritizing projects is similar to prioritizing tasks—it requires tough decisions, and will
almost always make someone unhappy. Priorities are always relative: each project’s stake-
holder feels that his project is the most important one. And in a way, he’s right—it’s the
most important one to him, but not necessarily to the organization. That doesn’t change
the fact that if there is a programmer available to work and there are two projects that
need to get done, a decision must be made to assign her to one project or the other.

While prioritizing projects seems to require the same actions as prioritizing tasks, it is
much more politically charged, and the project manager is under much more pressure to
throw away the prioritization entirely and pretend that all of the projects can be done at
the same time. This is usually a mistake—unless two projects do not share any resources at
all, there will come a time when a resource must be assigned to either one project or the
other. If there is no clear priority, this can create confusion and chaos.

Prioritizing projects is about making decisions. Someone has to put his foot down and say
that project A is more important than project B. In some organizations, this is the project

manager; more often, it is one or more senior managers (often a steering committee) who
have the authority to make the decision. One reliable way to figure out who should be mak-
ing that decision is to follow the money: the person who has the authority to allocate funds
to pay engineers and buy computers is generally the person who has the authority to decide
which project should be worked on first. Ideally, this responsibility should fall on a single
person (often the chair of the steering committee). If no decision-maker can be found, it
becomes the project manager’s most important responsibility to find that decision-maker.

Once the decision-maker is found, the process of prioritization is straightforward. It is sim-
ilar to the way risks are prioritized, with the exception that no two projects are allowed to
receive the same priority. Without this restriction, the team will end up with only top-pri-
ority projects. If the decision-maker has trouble choosing a priority, he can use the same
technique used for risk planning. If there are 20 projects to prioritize, he should identify
68 CHAPTER FOUR