Last Updated: August 10, 2026

Activity 10: Acquire Project Team

Acquiring a project team is first and foremost a project management activity, not a software activity. Project managers identify the people needed to complete the work, assign responsibilities, balance workloads, and resolve staffing conflicts before execution begins. Microsoft Project supports these decisions by providing tools that help assign resources, evaluate workloads, identify overallocations, and optimize the schedule. Throughout this Activity, you will learn both the management techniques and the software’s features that support them. 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.

Together, these techniques form the foundation of effective resource allocation, ensuring the right people are assigned to the right work at the right time while supporting a realistic project schedule.

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, start putting your project into action by bringing your team together. Learn how to swap out generic resources for real team members, check workloads, fix overallocations, adjust assignments based on who is available, and use the software’s Resource Leveling tools. Learn 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 transformed your project from a well-planned schedule into one staffed with the people who will actually perform the work. Generic placeholders will be replaced with named team members, workloads will be reviewed and balanced, and your schedule will more accurately represent how the project will be executed. This is the point where your plan begins to reflect the realities of managing a real project team.

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

Complete this Activity in the order presented. Begin by understanding the workflow, then reinforce the concepts through the exercises before reviewing your work and completing the Activity assessment. Each section builds on the previous one and prepares you for the next stage of the Project MAP framework.

Workflow (45 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 Acquire Project Team (15 minutes) jump to

This entire Activity Workspace should take 5 hours and 3 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, begin by making sure you understand the Acquire Project Team workflow. Notice how project managers move from planning to execution by assigning people to specific activities. 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.

Remember that generic resources represent required skills or roles rather than specific individuals. This approach is an important part of resource planning, allowing the project manager to determine what expertise is needed before deciding who will actually perform the work. Once the required skills have been identified, generic resources can be replaced with named team members who possess the appropriate qualifications and availability.

As you go through the workflow, notice how Microsoft Project helps identify overallocated resources, evaluate resource availability, adjust assignments and schedules, and build a realistic execution plan. You will also learn when to resolve conflicts manually, when to use the Resource Leveling tools, and how Resource Pools and Master Projects support resource coordination across multiple projects. Understanding both how these features work and why each step matters will help you create a technically sound schedule that reflects the people who will actually perform the work.

Learn Acquire Project Team Workflow (10 minutes)

(jump to the top of the page)

Activity 10: Acquire Project Team Workflow Chart

This workflow illustrates the overall process for acquiring and managing your project team. Although the steps are presented sequentially, experienced project managers often repeat portions of the workflow several times as staffing changes, workloads are balanced, and schedule adjustments are evaluated. Continue refining the schedule until the project team, assignments, and workload produce a realistic execution plan.

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 activity, check that they are available, and make sure their workloads are balanced so your schedule is realistic and achievable.

As you study this workflow, notice that each step builds on the decisions made earlier. Begin by replacing generic or skill-based resources with named team members. Then define their availability, review their workloads, and identify periods of overallocation or underutilization. Resolve conflicts by reassigning resources, changing assignments, adjusting Activity timing, or using Microsoft Project’s Resource Leveling tools when appropriate. Finally, establish Project Team Working Agreements so that team members understand how they will communicate, collaborate, make decisions, and resolve problems during execution.

Study this workflow before beginning the exercises. It illustrates the sequence of decisions used to replace generic resources, evaluate workloads, resolve conflicts, and prepare the project team for execution.

Complete the Activity 10 Exercises (3 hours, 10 minutes)

This exercise series is designed to reinforce the Acquire Project Team Workflow introduced earlier in this Activity. Rather than learning Microsoft Project commands in isolation, you will first practice each technique in a controlled exercise file and then consider how the same decision applies to your Master Project. The early exercises develop specific skills in resource replacement, availability, workload analysis, manual adjustment, automatic Resource Leveling, and cross-project resource management. Exercise 10.6 then brings those skills together in your Master Project. As you complete each practice exercise, identify the equivalent condition in your own project so that the final Master Project exercise becomes an application of decisions you have already considered rather than your first attempt to apply the workflow.

Complete these exercises in the order presented. The practice files provide a controlled environment for learning each technique, while your Master Project provides the environment for applying what you learned. After each practice exercise, complete the corresponding Master Project application before moving forward. This sequence will help you develop the project team gradually rather than postponing all staffing, availability, workload, and leveling decisions until the final exercise.

This exercise series follows the same workflow introduced earlier in this Activity. Each exercise reinforces a specific step in acquiring and preparing a project team for execution. You will begin by replacing generic or skill-based resources with named team members, then define their availability, evaluate workloads, resolve resource conflicts, share resources across multiple projects, and finally level your Master Project. Each exercise also produces a specific deliverable that becomes part of your Master Project, allowing your project to evolve from a planning document into a realistic execution schedule.

(jump to the top of the page)

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

This exercise reinforces the first step of the Acquire Project Team Workflow: replacing generic or skill-based resources with named team members. Begin in Acquire Team Overview.mpp to practice replacing resources and resolving a simple assignment conflict in a controlled schedule. After completing the practice file, open your Master Project and identify every generic or skill-based resource that can now be replaced with a named team member. Make the replacements for which staffing decisions have been confirmed, and document any generic resources that must remain because the individual has not yet been selected.

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.

IIn the Acquire Team Overview.mpp file, apply the Resource Graph view and use Zoom Entire Project. Select each resource in turn and review the graph to identify periods of overallocation, full utilization, and underutilization. This view provides a time-phased picture of the selected resource’s workload and helps you determine where schedule or assignment changes may be required.

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 the software. Like many other organizations, the usual reaction when a project started falling behind was to add more people. We could test this idea before actually bringing in extra workers. We created detailed schedules with expert activity 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 project plans. These plans showed not just the order of activities, 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)

One of the most important responsibilities of a project manager is making sure enough resource capacity exists to complete the project successfully. Resource capacity planning compares the amount of work required with the time each resource is actually available to perform that work. Microsoft Project helps accomplish this by allowing you to define calendars, maximum units, availability dates, and working time for every resource. In this exercise, you will configure resource availability so your project schedule reflects the real capacity of your project team rather than ideal assumptions.

The next workflow step is determining when those people are actually available. Begin by using Acquire Team.mpp to practice changing a resource calendar and defining time-phased availability. Then open your Master Project and review each named team member’s working calendar, Max. Units, known absences, part-time commitments, and changes in availability over the life of the project. Enter every confirmed availability condition before continuing so that the Calculation Engine schedules work using realistic resource capacity.

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 activity has been changed to accommodate this change. The activity was 3.17 days in duration and it has been changed to 5.17 days to accommodate Wendy’s availability.

Save this project.

(jump to the top of the page)

Exercise 10.3: Examine Resource Workloads (30 minutes)

Before a project manager can balance workloads or resolve scheduling conflicts, they must first understand how project resources have been allocated. Resource allocation is the process of assigning people, equipment, materials, and other resources to project activities to ensure work is completed efficiently and on schedule. Microsoft Project provides several tools for reviewing resource allocation, identifying overallocated resources, measuring remaining capacity, and evaluating the realism of assignments. In this exercise, you will examine how resources have been allocated across your project, learn to recognize common workload problems, and prepare your schedule for effective resource leveling.

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

Insert the Peak field in the Resource Sheet view. In this exercise file, the resources displayed in red have at least one period in which their assigned Units exceed their available capacity, and the Indicators column displays the overallocation indicator. Remember that Peak reports the highest assignment Units reached during any time period; by itself, it does not show how long the conflict lasts or which assignments caused it.

The Resource Sheet can display summary fields such as Peak, Work, and Overallocation, but it does not show the detailed time-phased assignments needed to diagnose when and why an overallocation occurs. To analyze the conflict, use views such as Resource Usage, Task Usage, Resource Graph, Team Planner, or a split view that combines resource information with the Gantt Chart.

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

Wendy needs to be there for this first activity, 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 first simulate general shifts in a schedule. 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 an activity or activities do not appear to be scheduled correctly, there are five things to initially check: 

1. The project or task calendar.

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

3. Timing constraints.

4. Check whether 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 milestone starts on 1/5. Then change the duration of Determine outcomes & scope that is 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 activity, 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 activities 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 shows a small overallocation during the first part of February. Before accepting it, determine the amount, duration, and cause of the conflict and confirm that the assignment is realistic. In this exercise, the project manager may decide to accept the limited overlap because Wendy’s involvement is brief and necessary, but that decision should be documented rather than ignored.

• 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 activities overlap. 

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

We will have to change the schedule, adjust her assignments, or a combination of both. Let’s say the best solution is to eliminate 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 activities 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 activity is delayed? What if we lose a resource? What if we add another crew? What if we change the order of activities? 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 activities connect, and seeing how those choices play out in the software, 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, activities #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 WBS element and remember the constraint on that milestone. Then insert the Total Slack field, and the problem is more apparent; there are 4.45 working days of negative slack on the last WBS element 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 having your budget trimmed or losing a valuable resource, you have to compensate elsewhere. 

In this case, look at the lag between Establish performance metrics and Obtain feedback. Perhaps the initial thinking was to introduce that much lag to improve the quality of the 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 activities coinciding. In addition, notice that Floyd is assigned to these three overlapping activities, 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 activities with the same people. 

Insert the Total Slack field, and #13 has 0 days slack, so we know that changing/delaying that activity 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, the most serious resource conflicts have been resolved, and the revised schedule now finishes on May 5 rather than May 3. Confirm that the project no longer has negative Total Slack. You may then change Tasks are critical if slack is less than or equal to from 0 days to 1 day in File / Options / Advanced to highlight near-critical Activities. This setting changes which Activities are identified and formatted as critical; it does not change the schedule logic, create additional slack, or improve the critical path itself.

Save the project. 

For each significant overallocation, record the affected resource, the conflicting Activities, the time period, the action selected, and the effect on the schedule. If a limited overallocation is consciously accepted, document why it is realistic and who approved the commitment. Your Master Project should now reflect deliberate workload decisions rather than unresolved software indicators.

(jump to the top of the page)

Exercise 10.4: Automatically Level Resources (25 minutes)

By this point in the workflow, you understand how to identify workload conflicts and resolve many of them manually. Use Resource Leveling.mpp to learn how the automatic Resource Leveling tools change Activity timing and how to evaluate those changes. Then create a backup copy of your Master Project and test the same leveling options against it. Compare the leveled and unleveled versions before deciding whether to retain, revise, or clear the leveling changes. The purpose is not to force every Master Project into an automatically leveled schedule, but to understand what the Calculation Engine proposes and determine whether those changes support the project’s objectives and constraints.

This Resource Leveling.mpp project is almost identical to the project we were working on 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 activity 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 activities #6 and #7. 

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

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

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

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

These steps shorten 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 activities 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 activities under Implement PMO shown below that have resource overallocations. One activity has 22 days of Total Slack, but two activities 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 an activity has been delayed by automatic Resource Leveling.

All resources are now leveled.

Format the Critical activities and save the project. 

(jump to the top of the page)

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

The Acquire Project Team Workflow may extend beyond a single project when the same people work across several schedules. This exercise uses practice files to teach Resource Pools, shared resources, and cross-project workload analysis. Complete the practice portion even if your Master Project is currently independent. Apply the technique directly to your Master Project only when it shares resources with other active projects or belongs in a consolidated master-project environment. Otherwise, record how the technique would be used if cross-project staffing conflicts later arise..

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

Notice that Resource Pool.mpp contains four resources but no WBS Elements, while the three project files contain WBS Elements but no resources. Microsoft Project does not use a special file type for a resource pool; it is a standard .mpp file designated as the source of shared resource information. Although an existing project can technically serve as the pool, a dedicated resource-pool file is normally easier to control, maintain, secure, and back up.

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.

Inserted subprojects may initially appear as collapsed Summary Elements in the master project. Expand a subproject to review or edit its detailed Activities. Keeping unnecessary detail collapsed can make a large master project easier to navigate and may improve responsiveness, but the source project remains linked whether the Summary Element is expanded or collapsed.

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 lets you assign a priority ranking to projects and activities during leveling. The ranking is from 0 to 1000; a ranking of 1000 means 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 activities. 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)

This final exercise is your opportunity to review and complete the Acquire Project Team Workflow in your Master Project. Most of the required information should already have been added during the earlier exercises: named team members, realistic availability, workload analysis, and documented conflict-resolution decisions. Use this exercise to identify remaining gaps, test or refine Resource Leveling where appropriate, evaluate the effect of all staffing decisions on timing, Work, cost, milestones, and the critical path, and confirm that the resulting schedule is ready to support project execution.

(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, the software 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

Field Note: The Promise and Reality of Automatic Resource Leveling

In the mid-1980s, personal computers started to change project management. Suddenly, we could run complex schedule calculations in minutes or hours, not days. Back then, I worked with Symantec's Timeline, which Breakthrough Software in Novato, California, originally developed. It was the first project management software for personal computers.

The introduction of automatic Resource Leveling was exciting for the company and industry. Reviewers were impressed that a computer could scan a whole project schedule and fix resource conflicts on its own. Early versions took almost 24 hours to process a schedule with about 1,200 tasks and a moderate degree of overallocation. Still, this was a big technical step forward.

As computers got more powerful, those calculations dropped to about 20 minutes, down from a whole day when I started working with project management software. The speed was impressive, but another issue appeared. While the software resolved many resource conflicts, the new schedules often stretched so far out that they no longer aligned with real business goals. The schedule was technically right, but not one anyone actually wanted to follow.

I remember working with a federal agency that was studying air traffic across the U.S. to help reduce congestion. Their method was simple: turn on automatic Resource Leveling and accept whatever schedule the software gave them. This surprised me, since in my experience, the software can't understand things like organizational priorities, contracts, customer needs, politics, or the many tradeoffs project managers deal with daily. Still, over the years, I've seen many organizations do the same, especially as projects get bigger and more complex, and manual workload balancing gets harder. As a consultant, I eventually set aside some of my general perspectives, and if a customer was determined to use the feature, I worked to help them get the most out of the tools.

I continue to believe that for most organizations, Resource Leveling is a powerful analytical tool, but it is not a substitute for project management judgment. The best project managers use it to explore alternatives, identify bottlenecks, and evaluate different staffing scenarios—not to make final scheduling decisions automatically. In this Activity, you are learning to think the same way: first, understand the resource conflict; then, use the software to evaluate possible solutions; and finally, apply your own professional judgment to select the approach that best supports the project's objectives.

At the same time, as the MS Project Master Class Book notes, some project managers have achieved impressive results 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.

(jump to the top of the page)