Allocating resources is the process of securing team members or other resources required to deliver the project.
Key to allocating resources is the project plan. It details what resources are likely to be needed to fulfill the delivery of products or more generally to execute the management of the project. The project plan should not only provide a reasonable estimate of the resources required for the project but should also provide a schedule for when the resources are required and for how long.
The Resource Allocation process is repeated at several stages throughout the project as needed. In the early stages of the project, a high-level requirement of resources will be needed, but as the plan is refined, further details are added which leads to more accurate demands for the resources.
Once the resources have been allocated, they need to be assigned to the appropriate project tasks.
What process should be undertaken for resource planning?
On one hand, Project Managers tend to desire receiving resource allocations from the Resource Managers as fast as possible. Indeed, the allocations enable them to plan their projects. On the other hand, these allocations ought to be truly reliable. Furthermore, Resource Managers face multiple difficulties:
Multiple Project Managers will send repeated requests to the same Resource Managers at different times.
Yesterday’s plan may be obsolete due to a new incoming request.
Team members are often assigned responsibilities outside of projects. This affects productivity in the projects.
To be successful the Resource Allocation process needs to have a suitable planning cycle. The length and duration of the cycle are to be defined in accordance with the lifespan of the project.
Therefore, the Resource Allocation process should be neither too complex nor too detailed.
The Resource Allocation flow represents the relationship between Project Managers (PM) and Resource Managers (RM) with respect to acquiring Resources and determining the Project-specific Resource Capacity of Team Members.
To support the different ways to work with Resource Allocations, Sciforma offers in the Default Configuration two types of Allocations distinguished by how they are created:
Direct Allocations for Allocations created by the Resource Manager without being linked to a Request. When using this type of Allocation, only one Allocation per Resource and per Project is possible.
Allocations that are linked to a Request whereby the Project Manager will be able to create multiple Requests per Project (at the Project or the Task level) and the Resource Manager will fulfill them with the Resource (Hard Allocation or Soft Allocation).
A Global Setting Enable Allocation Type will manage which type of Allocations can be used. Moreover, a Project setup option Allocation Type (picklist with values: Direct Allocations only, Allocations linked to Requests, Both - by default) will be available only if the setting Allocation Type is set to Both.
In the different situations presented below, shortcuts will be provided to address a situation where the Project Manager is also the Resource Manager of an Organization. Meaning that for Resources he/she manages, the Project Manager will have the ability to create allocations solely from his/her views.
Direct Allocations can be encountered within companies where the needs of resources are discussed during a weekly meeting between the Project Manager and the Resource Manager, or in cases where the Project Manager is also the Resource Manager of the Organization. In those situations, the Allocations will act as agreements.
In this use case, the Resource Manager creates the Allocations directly without receiving Requests.
In this situation, only one Allocation per Resource and per Project is possible.
In order to keep this use case as easy as possible, the communication between the Project Manager and the Resource Manager will be done through the Notes feature or outside this tool. No workflow or validation will be supported.
To address long-term needs, the Project Manager can create Allocation Requests. These requests will represent a “forecast” and can support the project cost estimation.
As with the first use case, the Resource Manager will be able to create Allocations without links to any request. These Allocations will act as the Resource Manager’s validation of the Resource capacity the Project Manager can use for his/her projects.
The two objects will be disconnected. Therefore, the Requests made by the Project Manager will not be used for the Allocation creation.
In this situation, the full lifecycle of the Resource Allocations feature will be considered, symbolizing the formal “contracts” between the Project Manager and the Resource Manager.
It requires the Project Manager to create a Request that will be reviewed and fulfilled by the Resource Manager.
This process will be driven by a workflow that will allow the Project Manager to accept or reject the Allocation, or even reopen the Request when the project plan is modified.
The Allocation Requests (if activated) will come with the following default workflow which a customer may choose to overwrite:
The workflow is meant to structure the communication between the Project Manager and the Resource Manager. It requires the Project Manager to create a Request that will be reviewed and fulfilled by the Resource Manager to finally be approved by the Project Manager.
With this workflow, reaching the final state of the Request corresponds to closing the Request.
Moving to the final state “Approved” has the following consequences:
The Resource Allocated Effort will be added to the Usable Effort of a Resource for a given Project.
The Resource will be added to the Project Team if this has not already been done.
Until the Allocation Request has reached the final state, the Allocated Effort will not be taken into account in the Usable Effort.
The Project Manager and the Resource Manager will only be able to edit the object they manage (Request or Allocation) when the Request state implies that the action would be on their side:
The Project Manager will only be able to edit the Request when the Request is on one of the Project Manager to-do states. He/She will not be able to edit the Allocations, except in the specific situation where the Project Manager is also the Resource Manager of an Organization.
The Resource Manager will only be able to edit the Allocations when the Request is on one of the Resource Managers to-do states. He/She will not be able to edit the Request, except if he/she wants to modify the workflow State, the Flag field, and the Notes.
The Reworked and Recalled status will allow the Project Manager and the Resource Manager to set the Request back to an editable state.
Some customers may want to be more strict and use a workflow without the possibility to recall the requests. They may also want to use a “faster” workflow by skipping the final Approval by the Project Manager (i.e., as soon as the Resource Manager has submitted the Allocations, the requests are considered as approved).
Note that if the Final State is on the Resource Manager side, the Resource Manager should have write access to the project to be able to perform these actions.