Many project managers are responsible for multiple projects . If each project is planned well, managing a set of them should not be difficult. When projects don't share dependencies, managing them is straightforward—just manage each project individually, with a separate project schedule for each one.
When projects share dependencies, they are more challenging to manage. There are two ways that one project might depend on another. In the first type, two projects rely on the same resources; in the second type, a work product generated by one project is needed by the other. Getting a handle on these dependencies is the first important step in managing multiple projects.
The most common way for projects to be interdependent is through shared resources. One instance of this happening is "pipelined" projects. In many software organizations, software projects go through a set of sequential phases: requirements, design, development, programming, and testing. In each phase, most of the work is done by a small subset of the team, leaving the rest of the team available to work on other projects. To allow the team to work at full capacity, they might be working on several projects at once. Project A is in the requirements phase, while at the same time, project B is in design, project C is in development, and project D is being tested.
The trouble with this system is that no two projects take exactly the same time, and the phases don't always require the same percentage of the total effort. For example, programming is typically 30% to 40% of the total effort of a project. But during that time, a lead tester might be working on a test plan, while programmers might have to stop work for half a day to review the requirements or design documents on another project. When there are more than two or three projects being worked on simultaneously, things can get very chaotic.
Usually, a programmer is fully allocated to a programming task. This means that the programmer is spending all of his time on that task (minus lunch, bathroom breaks, etc.) But in other cases, a resource will be only partially allocated to a task. For example, a conference room may be a scarce resource; it might be reserved only in the morning, but free in the afternoon. Or a designer might work on two projects at once, meeting with stakeholders for one project in the morning while analyzing usability lab data for another in the afternoon.
The project manager's first goal is to make sure that the shared resources are not over-allocated. If one project's schedule has a resource allocated 50% for the entire week, while another has that resource allocated 100% during the same week, that resource has a 150% allocation. Over-allocation problems often do not show up on the schedule.
What's more, if the estimates do not include overhead (going to meetings, reading email, helping customers, talking to senior managers, or other interruptions), then a person can be over-allocated even if the schedule says that she isn't. When taking effort into account on a project schedule, it's important to remember that even though people may be in the office for eight hours each day, they might only be available for project work for five of those hours. Also, the project manager must make sure that changes are controlled properly. If the scope of the project changes but the team is not given a chance to create new estimates, team members will almost certainly end up over-allocated.
Under-allocation is also a danger. If an engineer does not have any scheduled tasks for a week, she can easily get bored. That engineer may not be unhappy about the situation, but if the rest of the team is crunched for time, their morale will be impacted when they see their teammate take off early every day. One way to prevent this is to have low-priority projects where tasks can be assigned to under-allocated team members. However, enough time must be given to allow each person to ramp up on the task and finish enough to feel like the time was not wasted; otherwise, it just feels like busywork.
Modern project management software will often have a "resource pool" feature that allows a project manager to set up a single set of resources available to multiple projects. When a project schedule draws a resource from that pool, the allocation level for that resource is increased accordingly in the pool, so that allocation shows up on all of the 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.
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 stakeholder 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 making 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 similar 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-priority 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 top-priority project and assign it priority 1, then the lowest-priority project and assign it priority 20. Each additional project should then be prioritized in relation to those. (If it is absolutely impossible to decide the relative priority of two projects, he can flip a coin; if the coin's answer seems wrong, he should reverse it. This is a helpful way to "force" him to consider the alternative.)
The final result of the prioritization process is a list of projects that are arranged in order of priority, with a unique priority must be assigned to each project. This list of projects should also indicate which projects are dependent on other ones. This inclusion means that when a team member is identifying the next task to work on, its dependencies can be taken into consideration.
It is often tempting to assign the same priority to two different projects that seem to be equally important to the organization. It is sometimes difficult to make priority decisions; basically, they amount to deciding that one project may be delayed at the expense of another. But if these decisions are not made, that can lead to serious project problems. The most common problem is that the team ends up with several projects that are top priority, and it's not clear which one should be worked on next. This is bad because it's almost always the case that one of those projects really is more important that the others, so there is a good chance the team will work on a less important project. When many projects have a priority of 1 assigned, then the prioritization is essentially useless.
Once priorities are assigned to all projects, it's time to assign resources to the tasks. Each resource should be assigned to the next task on the project with the highest priority that does not yet have work being done. This is not necessarily a hard-and-fast rule: if a task on a lower-priority project must be done in order to make the schedules work out properly and to avoid over-allocation, the schedules should reflect that. And in many cases, there is only one person on the team who has the expertise to perform a specific task. But, wherever possible, the priorities should be honored.
Finally, a periodic priority meeting should be held to reevaluate the project priorities. Some organizations do this weekly, while others do it every two weeks or even monthly. This meeting can be piggybacked on the status meeting, as long as all of the project's decision-makers are there. The important part is that everyone is kept in the loop: the project manager, the lead decision-maker, and the stakeholders for the projects.
Get Applied Software Project Management now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
