After a long hiatus from weekly posts, I'll close out 2012 with my final “highlights of highlights” series: I include some excerpts from the Project 2010 Step by Step chapters and elaborate on them. This week: Chapter 18, "Consolidating Projects and Resources."
It might become difficult to coordinate the work resources’ time among the multiple projects, especially if those projects are managed by different people. For example, an editor at a book publishing firm might have task assignments for a new book, a promotional Website, and a press release—three projects proceeding simultaneously. In each project, the editor might be fully allocated or even underallocated. However, if you add all her tasks from these projects together, you might discover that she has been overallocated, or assigned to work on more tasks than she can handle at one time. (pg. 398)
Any organization that sincerely plans and tracks work in Project will sooner or later run into the gotcha of what I'll call "islands of MPPs." The issue is that if I manage my project in my MPP file, and you manage your project in your MPP file, but we're making use of some of the same people resources, then we'll eventually have a problem. That problem is described in the excerpt above. The coping strategy introduces what I regard as some of the cooler features of Project. These include the central resource pool and sharer files.
The resource pool is a project plan from which other project plans draw their resource information. It contains information about all resources’ task assignments from all Project plans linked to the resource pool. You can change resource information—such as maximum units, cost rates, and nonworking time—in the resource pool, and all linked project plans will use the updated information. (pg. 398)
This excerpt starts to describe the mechanics of a resource pool file and its sharer files. Because properly using a shared resource pool is difficult to visualize as an individual Project user, we spend a lot of time in this chapter setting up the scenario and walking through the exercises looking at this from multiple perspectives.
Any project plan, with or without tasks, can serve as a resource pool. However, it is a good idea to designate as the resource pool a project plan that does not contain tasks. This is because any project with tasks will almost certainly conclude at some point, and you might not want assignments for those tasks (with their associated costs and other details) to be included indefinitely in the resource pool. (pg. 404)
This excerpt comes from a sidebar titled "Creating a Dedicated Resource Pool" and the title sums up our recommendation. Elsewhere we also recommend storing the resource pool file at a network location that be accessed from the owners of all of the pool's sharer files.
A good way to pull together far-flung project information is to use a consolidated project. This is a project plan that contains other project plans, called inserted projects. The inserted projects do not reside within the consolidated project plan; rather, they are linked to it in such a way that they can be viewed and edited from it. (pg. 420)
Consolidated project plans (also called master projects and subprojects) is a feature that fits the project management model very well. That model is sometimes called a functional decomposition of a big complex thing into smaller, simpler component ingredients. In this section we create a master project plan and see how the subprojects behave both as part of the larger consolidated plan and as a normal, stand-alone MPP file.
Task relationships between project plans look similar to links between tasks within a project plan, except that external predecessor and successor tasks have gray task names and Gantt bars. Such tasks are sometimes referred to as ghost tasks because they are not linked to tasks within the project plan, only to tasks in other project plans. (pg. 423)
Creating a cross-project link is a rather peculiar process, which we illustrate in this section. However creating a cross-project link between subprojects within a consolidated plan is a more straightforward process (which we also illustrate).
Previous posts in the "Detailed Commentary" series:
Part 1, Simple Scheduling
- Introduction of Project 2010 Step by Step
- Chapter 1, "A Guided Tour of Project"
- Chapter 2, "Creating a Task List"
- Chapter 3, "Setting Up Resources"
- Chapter 4, "Assigning Resources to Tasks"
- Chapter 5, "Formatting and Sharing Your Plan"
- Chapter 6, "Tracking Progress on Tasks"
Part 2, Advanced Scheduling
- Chapter 7, "Fine-Tuning Task Details"
- Chapter 8, "Fine-Tuning Resource Details"
- Chapter 9, "Fine-Tuning Assignment Details"
- Chapter 10, "Fine-Tuning the Project Plan"
- Chapter 11, "Organizing Project Details"
- Chapter 12, Tracking Progress on Tasks and Assignments"
- Chapter 13, "Viewing and Reporting Project Status"
- Chapter 14, "Getting Your Project Back on Track"
- Chapter 15, "Applying Advanced Formatting and Printing"
- Chapter 16, "Customizing Project."
- Chapter 17, "Sharing Project Information with Other Programs"