Last Updated: July 6, 2026

Activity 10: Acquire Project Team

Once you have a solid project plan, the next step is to assign the people who will do the work and ensure you have the resources to complete the project. Microsoft Project offers several tools to help project managers replace generic resources with real team members, check workloads, resolve resource conflicts, balance assignments, and manage resources across projects. The main resource management features are:

• Replacing generic or skill resources with named people resources.

• Reviewing resource availability and workloads using Resource Views.

• Resolving overallocation by reassigning work, adjusting schedules, or modifying resource availability.

• Automatically leveling resources using Microsoft Project's Resource Leveling tools.

• Sharing and coordinating resources across multiple projects by using Resource Pools and Master Projects.

When planning a project, it’s normal to use generic roles like Programmer, Engineer, or Business Analyst while details are still being worked out. As the project moves forward, you need to replace these placeholders with the actual people who will do the work. Project managers also need to ensure workloads are reasonable, identify any overworked team members, and make changes before the project falls behind.

In the last Activity, Evaluate Risk, you examined project risks and identified possible events that could affect the project's schedule, cost, or success. This analysis helped you prepare for uncertainty by thinking ahead and planning how to respond before problems arise.

In this Activity, you’ll start putting your project into action by bringing your team together. You’ll learn how to swap out generic resources for real team members, check workloads, fix overallocations, adjust assignments based on who is available, and use Microsoft Project’s resource leveling tools. You’ll also see how to share resources across projects with Resource Pools and Master Projects, while keeping schedules realistic and workloads balanced.

By the end of this Activity, you’ll have turned your project from a detailed plan into one with real people assigned to each task. This will give you a practical and realistic plan that’s ready for a successful start.

New to the MS Project Master Class?

If you found this page through a search engine or external link, use the Start Here button below to learn about the Free and Complete MS Project Master Classes, the Learning Portal, Project MAP framework, Activity Workspaces, exercises, and the Master Project.

Activity 10 Workspace Outline

Activity 9: Evaluate Risk < Activity 10: Acquire Project Team > Activity 11: Create Project Compliance Plan

Workflow (30 minutes)

Exercises (3 hours 10 minutes) jump to

Exercise 10.1: Replace Resources and Replace Resource Assignments (15 minutes) jump to

Exercise 10.2: Define Resource Availability (15 minutes) jump to

Exercise 10.3: Examine Resource Workloads (30 minutes) jump to

Exercise 10.4: Automatically Level Resources (25 minutes) jump to

Exercise 10.5: Share and Level Resources Across Projects (30 minutes) jump to

Exercise 10.6: Level Your Master Project (60 Minutes) jump to

Update Journal on Acquiring and Leveling the Project Team for Your Master Project (15 minutes) jump to

This entire Activity Workspace should take 4 hours and 10 minutes to complete.

This Activity Workspace is part of the MS Project Master Class learning system and the companion Master Class Book available on Amazon. Many students also complete the Master Class with the assistance of a Master Class Coach or Trainer.

The project team acquisition, resource management methods, and best practices shared in this Activity Workspace come from over 35 years of experience teaching Microsoft Project, training consultants, deploying Project Server, and helping professionals around the world.

Internalizing the Activity 10 Workflow (25 minutes)

Overview and What You Will Learn

In this Activity Workspace, you’ll learn how to complete Activity 10: Acquire Project Team. You’ll see how project managers move from planning to execution by assigning people to specific tasks. You’ll follow the same steps that experienced project managers use to replace generic resources with real team members, check workloads, solve resource conflicts, and balance assignments throughout the project.

As you go through the workflow, you’ll see how Microsoft Project helps spot overallocated resources, adjust schedules based on who is available, and use resource leveling to build a realistic plan. You’ll also learn when to change assignments yourself, when to use the Resource Leveling tool, and how Resource Pools and Master Projects let several projects share resources easily.

By learning this workflow, you’ll understand how to use Microsoft Project’s resource management tools and why each step matters. This will help you build a solid and realistic project schedule.

Learn Acquire Project Team Workflow (10 minutes)

(jump to the top of the page)

Activity 10: Acquire Project Team Workflow Chart

The Acquire Project Team Workflow gives you a clear path from finishing your project plan to getting your project ready to start. In the planning stage, you figured out what work needs to be done. Now, you will choose who will do each task, check that they are available, and make sure their workloads are balanced so your schedule is realistic and achievable.

As you go through this workflow, you’ll see that each step builds on the last. First, you’ll assign real team members to tasks rather than generic roles. Next, you’ll check everyone’s workload to spot any issues, adjust assignments if someone has too much to do, and set up team agreements so everyone knows their role. These steps help turn a good schedule into a project plan that is well-staffed, balanced, and ready to succeed.

Complete the Acquire Project Team Exercises (3 hours, 10 minutes)

This exercise series focuses on Acquiring the Project Team. In this series, you will:

• Replace generic or skill-based resources with the people who will perform the work.

• Analyze resource workloads to identify overallocated and underutilized resources.

• Level resource workloads by:

  • Replacing or reassigning resources based on availability.

  • Adjusting the timing of activities.

  • Using Microsoft Project's automatic Resource Leveling tools.

• Share and manage resources across multiple projects using Resource Pools.

• Apply resource leveling techniques to your Master Project to create a realistic and achievable project schedule.

(jump to the top of the page)

Exercise 10.1: Replace Resources and Replace Resource Assignments (15 minutes)

In this first exercise, you will open the Aquire Team Overview.mpp file and replace generic resources with team members. In addition, you will level the workload of one resource by replacing them.

The project management idea is to plan with resource skills rather than people up to this point. Most of us don’t do that; we plan with the people on hand or in mind. The implications of planning with “skill in mind” are apparent. In the best-case scenario, we should ask, “What skill is required for this activity?” Not, “Who do I have available?”

The simple project you opened has five tasks and two skill resources assigned. The first step in the workflow is to replace these skill resources with actual people.

Open the Resource Sheet view and rename these resources with Ted, Susan, and Alice, in that order.

Ted replaces Project Manager

Susan replaces Software Engineer

Alice replaces Project Manager II

Illustration: Skyline Analogy for Leveling Resource Workloads

I grew up in Seattle and saw the skyline change a lot over the years. When the 38-story Smith Tower opened in 1914, it was the tallest building west of the Mississippi River. In the photo, you can see the Smith Tower as the small white building on the right with the pointed top. The Space Needle was built for the 1962 World's Fair, and after that, it felt like a new, taller skyscraper popped up every few years. Now, when I visit, the skyline is full of towers of all different heights, making it look unrecognizable if the Space Needle isn’t in the photo and clouds cover Mt. Rainer in the background.  

A resource histogram can change in a similar way. As you schedule activities and assign resources, some time periods get overloaded while others are barely used. If you don't pay attention, the workload becomes uneven, creating "skyscrapers" of resource demand. This can lead to overworked team members, schedule delays, burnout, and wasted project resources.

Washington, D.C., is very different. The federal Height of Buildings Act of 1910 limits how tall most buildings can be, so the Washington Monument stands out on the skyline. When I taught Microsoft Project to federal agencies in Washington, I would tell students, "This is how you want your resource histogram to look." Instead of big peaks and valleys, a well-leveled project spreads work out more evenly, making the workload easier to manage, more predictable, and less likely to cause resource problems.

Field Note: Matching Skills to People

In my experience with Microsoft Project Server, many organizations kept large enterprise resource pools filled with hundreds or even thousands of generic, skill-based roles. Instead of naming a specific person early on, project managers would assign roles like Senior Web Developer, Database Administrator, Business Analyst, or Quality Assurance Specialist. This way, projects could be planned around the skills needed, not just who was available at the time.

Resource managers handled the real people behind these roles separately. Each employee had a detailed skills profile in a database. For instance, Jane Smith might speak both English and Spanish, be skilled in SQL Server database administration, have experience in web development, and hold several Microsoft certifications. Someone else might have similar technical skills but not the language abilities needed for an international project.

When it was time to staff the project, Project Server’s resource-matching tools helped identify employees whose skills matched the generic roles in the plan. The system would suggest one or more qualified people, and the resource manager would check each person’s availability by looking at workload graphs, resource histograms, and current project commitments. If someone had the right skills but was already busy with other projects, they might not be chosen.

A specific person was assigned to the project only after both their skills and availability were verified. This method lets project managers create accurate schedules early on, and it helps organizations use specialized talent more effectively across different projects.

In the Aquire Team Overview.mpp file, ppply the Resource Graph view and then Zoom the Entire Project. This graphic clearly shows the allocation or workload for a selected resource.

Return to a Gantt Chart view. 

Resource leveling means addressing periods a resource is over and under-allocated and leveling their workload, so they are not experiencing times of overallocation when the quality of work goes down, and delays are a common outcome of over-allocation. Resource leveling also means looking for ways to better or more fully utilize resources, enhancing potential project contributions before their time is squandered. 

There are two ways to address overallocation: reschedule and reallocate. 

In this project example, both Task 1 and Task 2 coincide, and it is easy to see why Ted is overallocated 100% during this period. Link those two tasks with a standard dependency. By rescheduling Task 2, the overallocation is resolved. However, linking does cause a scheduling change and perhaps that change is not acceptable.

Unlinke these two tasks.

The other general approach is to adjust assignments. First, select Task 2, and then open the Assign Resources dialog box and replace Ted on Task 2 with Alice as shown in the figure below. 

Save the project. 

Field Note: Resource Planning at Hoover Dam

I fell in love with Hoover Dam as a young boy, so decades later I jumped at the opportunity to help modernize project management practices at one of the world's greatest engineering achievements. It was especially meaningful because Hoover Dam occupies a special place in project management history. The project is closely associated with the widespread use of the Gantt chart and demonstrates the importance of coordinating many large, interdependent projects simultaneously—an early form of what we now call portfolio management.

The International Association of Project Managers explains, "The Gantt chart is named after American engineer and management consultant Henry L. Gantt, who used it to provide a visual picture of the Hoover Dam project so that everyone involved could see when the individual construction phases were scheduled to take place." Even if Hoover Dam was not the first major project to use Gantt charts, it became one of the most famous examples of using visual schedules to organize thousands of workers, numerous activities, and highly complex logistics.

Frank Crowe was the Chief Engineer for the Six Companies group that built the dam. Besides his impressive engineering skills, Crowe stood out for his leadership and organizational skills. Building the dam was much more than just putting up a concrete wall across the Colorado River. The team first had to create roads, railways, tunnels, power systems, worker camps, and even a whole town in a remote part of the Southwest. Each of these was a big project on its own, and they all needed to be finished in the right order while sharing workers, equipment, materials, and money.

When I worked at Hoover Dam in 2007, I witnessed another interesting moment in its history. Michael Bay and Steven Spielberg were filming Transformers at the dam, while construction teams were building the nearby Mike O'Callaghan–Pat Tillman Memorial Bridge. At the bridge, a large bronze Gantt chart honors the planning and scheduling that made the years-long project possible.

My job was to plan maintenance for the generators. Hoover Dam's powerplant has 17 main turbines, with nine on the Arizona side and eight on the Nevada side. When a generator is shut down for maintenance, each hour it is offline affects how much electricity is produced and how much revenue is generated. That is why the maintenance schedule must be carefully planned and followed. A large printed Gantt chart is posted next to the generator so everyone—mechanics, electricians, supervisors, and contractors—can quickly see the schedule and know what needs to be done during each shift.

One of our main goals was to improve how they planned resources in Microsoft Project. Like many other organizations, the usual reaction when a project started falling behind was to add more people. With Microsoft Project, we could test this idea before actually bringing in extra workers. We created detailed schedules with expert task orders, different work shifts, special skills, and other staffing options. This lets us see what would happen if we added or removed resources before making real decisions.

The results often surprised us. Sometimes, adding an extra shift raised project costs by about $20,000 but shortened the schedule by only 10 minutes. These tests showed that simply adding more people does not always make a project finish faster. The real challenge is to match the right people with the right skills to the right activities at the right time. That is exactly what resource planning, workload analysis, and resource leveling are meant to do.

Another important goal was to keep the organization's knowledge alive. The maintenance manager I worked with was considering retiring after more than 30 years at Hoover Dam. Together, we recorded much of his experience in detailed Microsoft Project plans. These plans showed not just the order of tasks, but also the skills, decisions, and lessons learned from each maintenance project. In many ways, we were building a knowledge base for future maintenance planners.

One unexpected bonus for me was getting to spend time with someone who loved Hoover Dam as much as I did. After working there for decades, he knew almost every part of the facility and was happy to share its engineering history, how it operates, and many great stories. This remains one of the most memorable consulting jobs of my career.

(jump to the top of the page)

Exercise 10.2: Define Resource Availability (15 minutes)

In this exercise, we are going to take a closer look at these three things:

• Replacing generic or skill resources

• Viewing resource workloads

• Reassigning resources or modifying activities around resource availability

Replace Generic or Skill Resources

The first thing to do is replace the “skill” resources with a team of people. Apply the Resource Sheet view and make these changes:

• Sponsor = Wendy

• PMO Director = Susan

• PM Consultant = Ariel

• PMO Staff = Floyd

Defining an Actual Person’s Availability

After replacing “skill” resources with the actual people doing the work, define each person’s availability. Keep in mind that now you are dealing with resources that have commitments to other projects, line activities, time at the “water cooler,” conferences, training, and life experiences like vacations, maternity leave, and accidents and illnesses. Address resource availability by making the appropriate changes to their: 

• Calendar

• Exceptions to the base calendar

• Max Units

• Contour of availability

Let’s make some adjustments to Wendy’s availability:

• First, Wendy will not be back from the holidays until January 5th, so block off these dates in January (1/3-4/2022).

• Next, Wendy is available full-time for meetings and to kick off the project by spending several days determining the outcomes and scope of the project and aligning those with the business. Still, she isn’t available more than a few hours a week. Leave her Max. Units at 100% against her Standard base calendar but then contour her availability to 25%, beginning 2/1/2022.

When finished, you get a message that the duration of a Fixed Duration task has been changed to accommodate this change. The task was 3.17 days in duration and it has been changed to 5.17 days to accommodate Wendy’s availability.

(jump to the top of the page)

Exercise 10.3: Examine Resource Workloads (30 minutes)

Use the same Acquire Team.mpp file used in the previous exercise for this one.

The next step is to evaluate resource workloads. Insert the Peak field in a resource sheet view, and you can see that at some point in time (this could be during a 15-minute period), one resource is double-booked and two resources are triple-booked. All resources are highlighted in red, indicating they are overallocated. The indicators column also displays the overallocation indicator. 

There is no additional information about workloads in the Resource Sheet view. A closer look at resource over allocations must be observed and untangled in different views like the Resource Graph or Resource Usage views. 

Apply the Gantt Chart view. The Gantt Chart view identifies which tasks are associated with over allocations, and the dates of these tasks tell us where to look. 

Wendy needs to be there for this first task, so we have no choice but to delay the project before it even starts. The best way to do that is to change the project start to 1/5/2022. We already know that Wendy isn’t coming back from the holidays until 1/5/2022, so we might as well make that change to the overall schedule. 

Let’s simulate something about general shifts in a schedule first. Before changing the project Start date in Project Information to 1/5/2022, go to Options / Schedule and turn Calculation Off at the bottom. Then enter 1/5/22 in the Start date field in Project Information. Notice the schedule does not shift; the Project Start milestone is still 1/1/22. We know it did not change to 1/5 because we turned off Calculation. 

When a task or tasks do not appear to be scheduled correctly, there are five things to initialy check: 

1. The project or task calendar.

2. Calendar options for the project in Options / Schedule.

3. Timing constraints.

4. Check to see if Resource Leveling is set to Automatic.

5. Make sure Calculation is On in Options / Schedule.

Correct the problem by turning Calculation (a global setting that applies to all open projects) back On, and the Project Start task starts on 1/5. Then change the duration of Determine outcomes & scope that Microsoft Project changed to 5.17 days when Wendy’s availability was adjusted, back to 3.17 days. 

Also, notice the timing constraint on PMO complete. There is a Must Finish On constraint of 5/3/22. If you insert the Total Slack field, you will note that the schedule has several days of negative slack, so let’s make that correction by delaying the finish date. For the PMO complete task, go to Task Information / Advanced tab, and change the MFO date to 5/5/2022. 

From the Gantt Chart view in the figure below, we can see the tasks involved in the over allocations and we get a pretty good sense of the general time period, in this example last part of February and the first part of March, we need to look at closely to resolve these resource conflicts.

Apply the Resource Usage view. Adjust the time scale to week periods, because let’s say, that is the unit you are concerned about regarding over allocations. Then scroll to 1/30/2022 and make some of your observations and perhaps decisions. 

Add these details and color the backgrounds so that the rows are distinctive and shown in the figure below: 

• Work

• Work Avail.

• Rem. Avail.

• Overalloc.

• Unit Avail.

For example, you might make these observations: 

• As you already know, the resources are overbooked in February.

• Wendy is overallocated during the first part of February, and her over allocations are minimal, so we will not worry about it. We already rescheduled the project around her availability by delaying the project start date and changing the constraint date for the last task.

• Susan and Ariel are significantly overallocated during 1/30 and slightly overallocated during 2/6.

• Ariel is significantly overallocated during 1/30 and then not used at all beginning 2/20.

• Susan and Floyd are seriously overallocated during 2/27.

Select Wendy and then Apply the Resource Graph view. Zoom the Entire Project, set the timescale to weekly, and then scroll through the resources. 

Susan has the clear-cut case of the bottlenecks. There is a two-week period that it is not humanly possible to complete her assignments.  

Split the window and apply the Gantt Chart on the bottom view. Then scroll to 1/30. 

It is clear which assignments contribute to Susan’s overallocation, as shown in the following screen.

Let’s start addressing some of these more severe resource conflicts. Susan is assigned to ID #6 and #7. These tasks overlap. 

Please take a minute to look at her assignments for both tasks. 

We will have to change the schedule, adjust her assignments, or a combination of both. Let’s say the best solution is to get rid of the overlap. Double click on #7 to open task information and remove the lead for Determine process & procedures by entering 0 in the lag field under the Predecessors tab. 

The scheduling message below appears. This message is poorly written but still lovely to get. This message would have told you where to look for the problem in previous versions of MS Project. For now, remember the scheduling message associated and remember to look at the schedule to determine what has happened. 

Before looking for the scheduling problem, notice that you have resolved the overallocation for Susan during this period.

As is almost always the case, when you address an issue, such as timing, cost, resources, or scope, you create another issue you must address. Poor project managers spend much of their time putting out fires. This could be because they lack skills or work for an organization that poorly plans or executes. Good project managers problem-solve. They realize there are constant changes, disasters, challenges, and obstacles. They are prepared, and they have confidence in their plans.

Project Illustration: Planning for the Unexpected 1996 Summer Olympics

I lived in Atlanta during the 1996 Summer Olympics. In the months leading up to the opening ceremonies, newspapers and TV reports kept asking if the competition venues, transportation, and other facilities would be finished on time. To most people, it looked like everything was running late.

I remember seeing the program manager in charge of the Olympic projects being interviewed by a room full of reporters. They took turns asking tough questions about missed deadlines, construction delays, and whether the city would be ready for athletes from all over the world.

His answer stuck with me for almost thirty years. He calmly gave the same message to every question:

"We have looked closely at that. We have planned, and we are prepared. Even though it may not appear that we will be ready, we will finish on time."

What impressed me wasn’t just his confidence. It was the preparation behind it. He wasn’t just hoping things would work out. He knew the schedule, the critical path, the resources, the work left to do, and the backup plans already in place. He understood which tasks had some wiggle room, which didn’t, where extra help could be used, and which changes would matter most.

That experience taught me an important lesson I’ve seen again and again in my consulting work. Experienced project managers are rarely caught off guard by problems because they’ve already thought through many of them. They keep asking questions like: What if this task is delayed? What if we lose a resource? What if we add another crew? What if we change the order of tasks? They consider different options before a crisis occurs.

That’s exactly what you’re learning to do in this activity. By examining resource workloads, swapping or reassigning resources, adjusting how tasks connect, and seeing how those choices play out in Microsoft Project, you’ll be ready to respond confidently when things change. The goal of resource planning isn’t just to make a schedule. It’s about understanding it well enough that, when problems come up, you already know your best options.

To address scheduling problems, the best view to apply is the Gantt Chart. In the project file, we are using, tasks #6 and #7 are no longer overlapped in the Gantt Chart view, but what was the scheduling message trying to tell us? Look at the last task and remember the constraint on that task. Then insert the Total Slack field, and the problem is more apparent; there are 4.45 working days of negative slack on the last task created by the slip in the schedule. The project needs to be brought in to resolve this scheduling problem. 

Typically, when you adjust one project constraint, such as getting your budget trimmed or losing a valuable resource, you have to compensate somewhere else. 

In this case, look at the lag between Establish performance metrics and Obtain feedback. Perhaps the initial thinking was to put that much lag there to increase the quality of input obtained. Reducing that lag would reduce the scope or quality of the project if it hinges on the quality of the feedback, but it seems to be the best way to address this scheduling problem. But how much do you reduce this lag? Well, the Total Slack field tells you 4.5 days. 

Change the lag from 30 days to 25.5 days.

Notice the Total Slack is now zero, and the scheduling problem was corrected. 

Go back to the Resource Usage view, with the Gantt Chart view on the bottom of a split window. Select Susan, and we can see that the next problem we need to address is her assignment to three tasks coinciding. In addition, notice that Floyd is assigned to these three overlapping tasks, too, and Ariel is available during this period. 

So let’s do these three things: 

First, let’s remove the overlap between ID #12 and #13. It would be nice to do these together; we can’t staff the tasks with the same people. 

Insert the Total Slack field, and #13 has 0 days slack, so we know that changing/delaying that task will delay the project. But go ahead, double click #13 and change the type of dependency from a Start to Start to a Finish to Start.  

Then, with the Gantt Chart view selected below, open the Assign Resources floating dialog box (Resource tab / Assign Resources command) and do the following: 

Replace Susan on #10 and #13 with Ariel. Susan’s overallocation is resolved. Ariel now has a heavy work week on 3/6, but it is low enough for her to level. The following week she has a low assignment, and then she is open.  

Finally, select Floyd. He is overallocated the weeks of 3/6-3/13. Suppose both Susan and Floyd had wanted to work on Establish monitoring criteria, but now it doesn’t seem practical given the over allocations. Let’s let Susan do the bulk of the work. Reduce Floyd’s assignment on #12 and #13 to 10%. That keeps him involved but doesn’t require a lot of work. That brings down his overallocation to something he can manage. 

In this exercise, we have resolved (to our satisfaction) the resource conflicts, and we have addressed some of Ariel’s underutilization. Let’s take a final look at the schedule by applying the Gantt Chart view. There are still over three days of negative slack. Shorten the lag of Obtain feedback to 22 days. 

Now the schedule looks good. 

In summary, we resolved the serious over allocations in the schedule. The project is only finishing a couple of days later (5/5 vs. 5/3) than when we started trying to schedule the actual people doing the work. We have a small amount of Total Slack built into the schedule, but we can redefine Critical Path in Options / Advanced to 1 days. This is done on the Tasks are critical if slacks is less than or equal to: selection at the bottom of that dialog box. Change the definition of the critical path, and then show Critical Task (Format tab / Bar Styles group / Critical Tasks checkbox command) and notice there is now a clean Critical Path flowing through the project. 

Save the project. 

(jump to the top of the page)

Exercise 10.4: Automatically Level Resources (25 minutes)

Although rarely used successfully, expectations for automatic resource leveling are typically disappointing. However, we believe that automatic leveling can be very successful under a specific set of conditions, and almost anyone could effectively use a hybrid approach.

This Resource Leveling.mpp project is almost exactly like the project we were working with above before we manually leveled resources.

We already know there is not much slack in the schedule, so the Must Finish On constraint has been removed on the last task because we know leveling is likely to push out the project end date. Automatic resource leveling will delay the project and may only be an appropriate feature to try if the finish date can be reasonably extended. 

A hybrid approach is the best one to take when using automatic resource-leveling. First, if you have available resources, replace overallocated resources and then try automatic leveling. Make a few adjustments, level, remove leveling, make a few more adjustments, level again, and try a couple of iterations of this. 

Open the Assign Resources floating dialog box using the command on the Bridge Quick Access Toolbar and select tasks #6 and #7. 

• Reduce Susan and Ariel’s assignment to each task to 50%. We know Wendy is only available at 25%, and she really should be assigned to both tasks, so assign her at 12%.

• Floyd is available, so assign him to both tasks at 50%.

That resolves the conflicts on these two tasks. Notice the overallocation indicators are gone. 

Next, since we are attempting to utilize resources better, let’s use this opportunity to shorten the schedule a bit. First, overlap the last two detail tasks by making the dependency an 15FS-4 days. Wendy should be assigned to #15 and #16 at 12%. Assign Ariel to both tasks at 50% and reduce the assignments of Susan and Floyd to 50%.

These steps shortens the schedule by several days, and the assignments are improved. In addition, when thinking about it, it would be good for the entire team and the customer to be involved in these last two tasks so an assumption might be that performance has increased.

Select #12 and #13 and assign Wendy at 10%, Assign Ariel at 50% and change the assignments of Floyd and Susan to 50%.

Then automatically level the remaining overallocations.

First, add the Leveling Delay and Total Slack columns.

Notice the three tasks under Implement PMO shown below that have resource overallocations. One task has 22 days of Total Slack, but two tasks have zero slack so leveling could delay the project.

Click the Leveling Options command on the Resource tab and make the selections in Resource Leveling dialog box in the figure below.

Clicking the OK button will save your selections in this dialog box. In this case, select Level All to level.

All of the schedule changes made by resource leveling are temporarily highlighted in blue. The Leveling Delay field show how much as task has been delayed by automatic resource leveling.

All resources are now leveled.

Format the Critical Tasks and save the project. 

(jump to the top of the page)

Exercise 10.5: Share and Level Resources Across Projects (30 minutes)

In this section, we will share and manage resources across projects. In addition, we are going to level resources across projects automatically.

Before we start the exercise, review each of the files.

Notice that the Resource Pool.mpp has four resources but no tasks, and the other files have tasks but no resources. The file you use as the resource pool could be a current project. This file is designated as the resource pool .mpp file but is just a regular *.mpp file. No selection in Microsoft Project makes it a resource pool file.

Step1

The first step in sharing resources across projects is to create the resource pool file. Again, the resource pool file is a regular Microsoft Project *.mpp file. It has no unique characteristics. However, most people create a resource pool file and enter and define all of the resources in a Resource Sheet view.

Step 2

The Resource Pool.mpp file will be the resource pool in this exercise. To share those resources, select an existing project that you want to share the resources from the resource pool file, and then from the Resource tab, click the Resource Pool command and the Share Resources…command.

An individual project can still maintain its own local resources, but if there is a naming conflict, the defined resource in the pool should take precedence or be used instead of the resource in the project.

Step 3

To view workloads across projects, create a master project by opening a blank project file and then insert the projects that share resources into this file by going to the Project tab / Subproject command, checking Link to project, selecting the projects, and then clicking Insert.

Projects are always inserted as collapsed in order to save time loading and to prevent crashing. When a project is expanded, the rest of the data from that project is loaded into the master.

Projects can be inserted read-only or read/write. If you want to make changes in the master file, like leveling resources, changes you want to save back to the source projects, insert the projects as read/write.

Next, let’s share resources for the first project together, and then you can do the other two projects independently.

With the Resource Pool.mpp file open, open or select the Deployment Project.

• Share the resources from the resource pool by selecting the Resource tab, click the Resource Pool command and Share Resources… Select the Resource Pool.mpp and make sure the pool has precedence.

• Then open the Assign Resources floating dialog box and assign all four resources at 100% to the three detail tasks as in the next figure.

Follow the same steps for the other two projects, HR Project and New Software Project.

When finished, save all three projects and close all projects including the resource pool.

Next, insert the three projects (not the resource pool) into a blank (Master) project as shown below.

When you click Insert, by default these projects are inserted into the master project as read/write. Place the projects in the same order on the screen below.

Expand each project. As you do this you will be asked to open the resource pool file so that resources can be viewed across the sharer files. Click OK.

After expanding the projects, it is easy to assume there are resource over allocations or conflicts since the projects overlap. Let’s look at some of these allocations.

Apply the Resource Graph view, split the window and show the Gantt Chart on the bottom. In the Gantt Chart view, insert the Project field so that you can identify which tasks (since the names are the same) are associated with which project.

It is easy to see that Alice, for instance, is overallocated. Select the Format tab on the ribbon and note the different graphs that are available.

Return to the Gantt Chart view without a split window and insert the Leveling Delay and Priority fields.

These resource over allocations can be resolved in the master project in the same way they are resolved in a project. Automatic Resource Leveling can also be used. If you use automatic Resource Leveling, we recommend using a hybrid approach as illustrated above.

If you use automatic Resource Leveling the Leveling Delay field will let you know in elapsed time how much a task is delayed by leveling. The Priority field allows you to give projects and tasks a priority ranking when leveling. The ranking is 0 to 1000, a 1000 ranking means that the task will not be leveled at all. A task with a ranking of 1, will be delayed before a task with a ranking or priority of 2.

Let’s give this a try. Give the Deployment Project a priority of 1000, make the same selections in Leveling Options as shown in the figure below, and then Level All.

You can apply a hybrid approach to this, but resource leveling across projects can go a long way toward preventing bottlenecks in an organization's project worktraffic flow.

Close the master project and there is no reason to save any changes. A master project may be temporarily created for a specific purpose with no intent of using the file again. When closed, you will be asked if you want to save changes to the source projects including the resource pool file. Save only the changes to the software project and then do these three things:

1. Open the New Software Project.mpp. Disconnect this project from the resource pool file. Resource / Resource Pool / Share Resources / Use own resources. Notice, that you still keep the resources from the pool file that you assigned to tasks. A possible scenario might be one in which an individual in the organization maintains the resource pool files, and project managers use this file only when building their team of resources for a project. After assignments are made, they use their pool, unlinking to the resource pool file.

2. Apply the Leveling Gantt view to this project. This view clearly identifies the schedule results of automatic leveling.

3. Save the project.

(jump to the top of the page)

Exercise 10.6: Level Your Master Project (60 minutes)

Open your Master Project and do two things. First, replace generic or skill resources with the people doing the work. Then, level resources to your satisfaction.

Then compare your current timing (start, finish, and duration), work, and cost with your baseline information on the summary level.

(jump to the top of the page)

Review Microsoft Project Features Used in Activity 10 (5 minutes)

Resolving Resource Overallocations

No one has unlimited resources. The better people plan, the more they realize they must address resource overallocation and underutilization. 

As a project is examined from various perspectives, Microsoft Project does a great job of identifying resource allocations over time. 

Four views are almost exclusively dedicated to viewing resource workloads: 

• Team Planner view

• Task Usage view

• Resource Usage view

• Resource Graph view

Resource Leveling

In the mid-80s, software development rapidly solved problems and performed tasks in minutes or hours that once took days.

When Resource Leveling was first available for project managers using a PC, a 1,200-task schedule with moderate resource overallocation took 24 hours to level resources.

The software reviews literally “went nuts” about how great that was. There was this implicit promise that you could plan however you wanted, and the software would untangle the mess and resolve all of your resource conflicts. This was a fascinating idea for many people.

As it turns out, Resource Leveling has never been a magic bullet. Most people give up on the feature without discovering circumstances that could make it valuable. At the same time, in some instances mentioned in the MS Project Master Class Book, some project managers have accomplished incredible things using this feature.

Like Resource Leveling, sharing resources has been a staple of project management software since the mid-1980s.

Sharing resources across multiple projects and then combining those projects into a master project has been a handy tool over the years. Download the

(jump to the top of the page)