Using Resource Requests

This article explains the resource request process from both the project manager and resource manager perspective.

Effort Forecasts and Requests

In order to fully understand how to best define a request process for your organization, you must first understand the effort forecast process.

An effort forecast is a time-phased project labor assignment, at the skill or named-resource level. In other words, for each project, it includes the skills and resources reserved for that project across the future timeline.

There are multiple approaches to maintaining effort forecasts (labor assignments).  Prior to deciding whether and how to use Resource Requests, it is best to read the article Recommended Demand and Capacity Workflow, which outlines the approaches and the pros and cons of each.

The Request/Approval Method outlined in the linked article above involves the resource manager manually reviewing and approving requests, and is thus the focus of the remainder of this article.

Skill-Level Requests

Requests can be at a skill level or resource level. Skill level requests are useful for long and medium term forecasting, when it is not yet known who the named resource will be. It is also useful in larger or more formal organizations where a project manager is unlikely to know the exact person required, or where there are multiple resources with similar skills. It also gives the resource manager more control over his/her own staff and allows responsibility for choosing who to assign and when. In some cases, the skills may be available elsewhere in the organization.

Note that in some organizations or situations, it may be perfectly fine for a project manager to request a named resource, saying, “I need Joe for two weeks in June. He’s the only one capable of doing what I need, and the only one I trust.” (Of course the resource manager then has the right to say, “Well you can’t have Joe, but we have someone else that’s almost as good.”). In a larger or more formal organization, the project manager would instead say, “I need a skilled Oracle DBA for two weeks in June,” and the resource manager would worry about who to staff at the time requested.

About Requests

When using a manual request/approval process, project managers do not revise and save effort forecasts directly, nor are requests auto-approved. Instead, any forecast entries or revisions project managers make (at a skill level or named resource level) are submitted as “requests” to the appropriate resource manager (determined by whoever is authorized to manage the resource OBS level that the resource belongs to).

TIP: It is important to note that each resource manager is accountable for the overall effort forecast for his/her resources. Only the resource manager (and perhaps the resource) has the full picture of the resource’s intended workload, including project and non-project work.

How the Project Manager Submits Requests

There are two ways a project manager can submit resource requests.

One is via the Assignment page, with new or revised skill or resource assignments being submitted as requests. (Or on the Project or Resource Assignments page for an individual project or resource). This is the preferred method.

The other is via the Assignment page Project Scheduler (the Schedule sub-tab under the project workspace), where forecast adjustments can be requested based on task level assignments. This method should be used with caution.

Let’s look at both:

Effort Forecast Requests

On the Assignments page, when adding new skill or resource assignments or modifying existing ones, project managers do not directly save their changes to the database (assuming the Resource manager-driven approach). Instead, after additions/changes have been made, all of the changes in that context can be submitted by clicking the Request icon, located in the top left control panel:

NOTE #1: In the Request/Approval Method, a project manager is not generally authorized to save to the effort forecast directly. However, if you, as a project manager, ARE authorized to save to the forecast directly, but want to send a request anyway, be sure to click the Request button BEFORE clicking Save. The Request button only submits requests for forecast changes made since the last save. Note that clicking the Request button will submit the request AND save to the database.

NOTE #2: Once a request has been submitted, the forecast will revert back to the original numbers prior to the requested amount until the request has been approved by a resource manager.

To see status of pending/historical requests, click the Requests tab in the Projects area. The Open/Rejected/Approved filters in upper right can be used to limit the requests shown. The leftmost column will show the status (Accepted, Rejected or Under Review) for each request. A project manager cannot approve/reject their own requests (under the recommended configuration), but is generally authorized to view his/her own request submissions.

Note the Org column. This represents the Resource OBS Node (i.e., where in the organization) the resource falls under, and thus where the request was sent. Whoever has authority to that level of the Resource OBS will be able to see the request.

TIP: It is a best practice to authorize resource managers to other “sister” nodes in the resource structure. After all, a resource manager may be able to fulfill needs outside of his/her own department.

Important: Until the responsible Resource Manager accepts/acknowledges your requests, they will only be in the temporary request queue visible to the resource manager, not yet in the shared Assignment context.

Task Assignment Requests

On the Project Schedule (the Schedule sub-tab) in the project workspace, project managers may enter task level named-resource assignments by allocation unit percent (e.g., 50% of Jim’s time and 25% of Sally’s).

Clicking the Resource Histogram button will open up a bottom pane showing any discrepancies between the task units assigned and the existing effort forecast. Then, clicking the Requests button will submit requests for the difference (either plus or minus) for all tasks on the project. Thus, it is vital to only submit the request AFTER all task assignments for the project have been entered. Use this approach with extreme caution.

For more on task level assignments and the related request process, see the article on Adding and Editing Projects.

How the Resource Manager Responds to Requests

As a resource manager, you will have a queue of pending requests (usually from project managers) that you should regularly address. To do so, click on the Requests tab in the Resources center. The Open/Rejected/Approved filters in upper right can be used to limit the requests shown. The second column from the left (to the right of the checkboxes) contains a symbol for the Request State:

• <empty> = Open
• Checkmark = Accepted
• X = Rejected

To Accept/Reject/Review/Delete each item, select the row and use the corresponding icons in the upper left.

Note that you can only accept or reject an entire request. There is no current capability for accepting partial requests. However, we are in the process of revamping our request functionality, so stay tuned for exciting new features! Regardless, it is a best practice for resource managers to talk with requesting project managers about their requests, to validate needs and discuss discrepancies.

Merging Requests

Requests can be manually merged. Merging requests will result in one open request combining all the values of the source requests, and all other requests in the set rejected.

To use this, on the manage request page, select the requests you want to merge values for, and then click the Merge Requests button.

The values of the selected requests will be combined to the first selected request row. That first request stays in open state and all others get rejected.