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 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 two approaches to maintaining effort forecasts. The most frequently used and generally recommended one is a Resource Manager-Driven Approach. This means that the resource manager is the only one authorized to directly enter or revise effort forecasts. The project manager can only "request" skills or named-resource assignments. The resource manager then fulfills the request. This approach offers pros and cons:
Pros: The resource managers are involved from the beginning, and have full control over their resources' workload balance. The resource managers are generally the only ones with the full picture of their staff's intended workload (project and non-project) and thus maintain full control.
Cons: The project manager must request skills and/or named resources and wait until the resource manager approves them. This can cause slight delays if resource conflicts arise or if resource managers are slow in responding. To minimize bottlenecks, the resource manager must check for pending requests regularly.
The other approach is the Project Manager-Driven Approach. In this scenario, the project manager either can submit auto-approved requests, or, if authorized, they would just enter their project's skill needs and/or named-resource assignments directly to the effort forecast, even if it means overbooking certain resources. This should ideally happen after a conversation with the respective resource manager(s) to minimize later conflicts (which would slow the project down and thus defeat the purpose of this method).
Even in this approach, the resource manager must still maintain accountability for the overall effort forecast for their resources. Since the forecast would be mostly maintained by the various requesting project managers, it becomes imperative for the resource manager to regularly look for overcommitment situations for their staff, using dashboards and utilization reports, and suggesting changes as needed.
Pros: It can possibly reduce bottlenecks for project managers, speeding up the project delivery process (though sometimes, the bottlenecks are to resolve valid resource conflicts). The resource managers don't need to check pending requests (though they SHOULD be involved in project staffing conversations and regularly review their team's utilization for overloads).
Cons: It requires that project managers talk to resource managers prior to assignments (which often doesn't happen) and it requires resource managers to regularly view reports to address overloads (which wouldn't be necessary if they'd had more control over the assignments to begin with). If these conversations and overload-handling processes don't happen, then the result is overworked resources and project delays. If they do happen, the process can work quite well.
With either method, the resource managers must take an active part: either approving requests or participating in project staffing conversations and reviewing utilization reports for overloads.
Which approach you take depends on the culture of your organization and the preference of the collective resource managers. The Resource-Manager Driven approach involves requests, and is thus the focus of the remainder of this article.
Skill-Level Requests and Assignments
Whether or not to use skill level requests and assignments is also a consideration. Skill level requests/assignments 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 a small organization, 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.
Under the Resource Manager-driven configuration, project managers do not revise and save effort forecasts directly. Instead, any forecast revisions they make (at a skill level or named resource level) are submitted as "requests" to the appropriate resource manager (determined by 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 Forecast tab, with new or revised skill or resource assignments being submitted as requests.
The other is via the Project Scheduler (the Schedule sub-tab under the project workspace), where forecast adjustments can be requested based on task level assignments.
Let's look at both:
Effort Forecast Requests
On the Forecast tab, 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 (the button to the right of the X in the image below):
NOTE #1: In the Resource Manager-Driven Approach, 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 center. 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 Forecast 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.
For more on task level assignments and the related request process, see the article on Adding, Editing, and Scheduling 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 leftmost column will show the status (Accepted, Rejected, or Under Review) for each request.
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.