5 Lessons on Microsoft Project Resource Engagements

In June 2015, when Microsoft first talked about the new resource engagements feature for Project Online and Project Server, there was great excitement in the project management community. We were finally going to have a formal way of managing the negotiation between project managers and resource managers by specifying the amount of work and time a resource could be associated with a project.

More than a year has gone by since the new capability was introduced, and we think it’s a good time to share five lessons on how to maximize the use of this feature.

Lesson #1: Set Human Resources to Require Approval for Assignments

While not all resources in the organization require an approval before they can be assigned to tasks, at the least, it’s recommended that the high-demand human resources are set to require approval. This setting is beneficial for both project managers and resource managers, as they will have to work together to agree “in the calm and quiet of planning” on the utilization of resources.

To set the resource to require an approval, follow the steps below. (You’ll need to have the right permissions in order to perform this action.)

1. Open the browser and go to your Project Web App (PWA) site.
2. Click on the Resources link and then in the Resources tab.
3. Select one or more resources you want to set to require approvals. If you’re selecting just a single resource, then click the Edit button. (If you’re selecting multiple resources, then click the Bulk Edit button).
4. Check the Resource Requires approval for all project assignments option and then Save.

Setting this flag ensures the availability of these key resources is managed through Resource Engagement,. And it should significantly reduce the instances of multiple projects using the same resources and “burning them out” due to over-allocation.

Lesson #2: Project Managers Must Submit Multiple Engagements

It used to be that when using the “old” resource plans and a project manager needed more than one resource with the same role to work on a project, it was common practice to set the units of the generic resource to match that need. This way, if we needed two business analysts for the month of July, we could create a resource plan and set the work units for that month with 320 hours (or simply set the work units as “2 FTEs”).

With resource engagements, the scenario changes. Now, if we need two business analysts for July, we recommend creating two separate engagements, each one representing one resource specifically:

Why? Because the resource manager won’t be able to assign two named resources to a single engagement proposed at 200 percent. In other words, the resource manager can’t split an engagement in two. So, the ideal scenario is for the project manager to create one engagement for each needed resource. Then, the resource manager will be able to assign a resource to each request individually.

The same scenario applies when a project manager needs to extend an engagement because the dates on the project have changed. Let’s say you have two business analysts committed for the month of July, but the project gets into execution and for some reason is delayed and you’ll need to extend the engagement for the two first weeks of August. We recommend creating (and submitting) a new engagement representing the request to extend these resources. This engagement alerts resource management to the change, and you can work with them through resource engagements to find a staffing solution supporting both your project and any other projects the business analysts were scheduled to work on at the beginning of August, as shown in this screenshot:

Lesson #3: Human Resources are Added to Your Team, But Aren’t Assigned to Tasks

When you create a new project in PWA, the initial project schedule may also have the generic resources assigned to some tasks in your schedule (primarily when the enterprise project type has a project template assigned to it). These generic resources are the perfect starting point for creating your initial resource engagement requests; however, it’s VERY important to know when a resource manager accepts the proposed engagement and commits it with a human resource, they won’t actually replace the generic resources on the assignments.

So, even though you have the human resource available to work on your project, the replacement process for the tasks will have to be done manually.

Lesson #4: Committed Human Resources Are Not Changeable

When a resource manager replaces a generic resource with a human resource and commits to a resource engagement, he or she won’t be able to change the committed human resource. If the person who has been given to the project manager isn’t appropriate and needs to be replaced, the original engagement needs to be deleted and a new one has to be created and submitted for approval.

When editing a committed engagement, project managers will be able to change Start and Finish Dates, as well as the Units or Work that have been committed — but won’t be able to change the actual committed resource, as shown here:

Lesson #5: Violations of Committed Engagements

When all the Resource Engagements have been negotiated and approved and the planning phase has ended, the project moves into execution. Once in execution, we can experience changes in the resource requirements for a number of reasons. If any change in resource usage violates the committed engagements, then Microsoft Project will inform you with some wonderful new icons in the “Indicators” column. There are three main ways that the engagement rules can be violated:

• When a resource (human or generic) is set to always require approval, and no engagements are committed prior to assigning this resource to tasks in a given project;
• When the task assignment is outside the boundaries of a committed engagement; and
• When the work required for the assignment is beyond the committed work that has been approved and the resource requires approval.

You can use the “Engagement Inspector” to identify what is causing the engagement to be violated, as well as to apply the actions to solve it:

Scenario 1: A resource that requires an approval is assigned to a task, but no engagement has been committed:

Scenario 2: The assignment is outside the boundaries of a committed engagement:

Scenario 3: The work required for the assignment is beyond the work approved on the engagement:

4 Final Observations

To wrap up this article, we offer these four general comments and observations on the use of resource engagements:

• To be able to submit an engagement, the project needs to have been published at least once. In cases in which you save a local .mpp file to Project Online or Project Server without publishing it, you’ll be able to create engagements. (The “Submit” button will be grayed out until the project is published.)
• Engagements (proposed or committed) aren’t tied to the dates in the schedule, but each task/resource assignment is validated against the engagement. This means if you create engagements that don’t match with the schedule’s dates, you won’t be notified of this until the resources are, in fact, assigned to tasks.
• If an engagement has been proposed (but not committed) and the resource is assigned to tasks matching the engagement, Project will display a gray icon in the “Indicators” column saying that the assignment is covered by an engagement not yet committed.
• Changing the Calculate Resource Utilization from option in Project from “Resource Engagements” to “Project Plan” or to “Project Plan until” won’t prevent the software from checking for violations to the engagements rules.

A version of this article originally appeared on the Sensei blog.

Image Source

Steve Caseley, is a PMP, PMI-ACP, a Scrum Master and a Principal Consultant. Steve has worked in the project management field for over 25 years, and has a wealth of practical experience in successful project delivery. As a result, he has many battle scars, but none have been fatal. Over the years, Steve has helped a wide range of companies implement PPM Systems and Best Practices and has practical, hands-on PM experience in a wide range of industries, project types and sizes. Steve’s passion is working with organizations to improve overall project delivery efficiency through the implementation and adaption of Industry Best Practices in Project and Portfolio management and implementation of effective PPM tools supporting these best practices. Steve has presented at international PM conferences and Microsoft Project User Groups over the years.