Understanding Placeholders in Resource Allocation
When planning and managing projects, it’s not always possible to assign named resources straight away. Project managers often need flexibility to plan with unknowns, whether that’s an unidentified individual, a pool of skills, or a delivery team. This is where placeholders come in.
Fluid supports three types of placeholders: Resource Placeholders, Team Placeholders, and Pool Placeholders. Each serves a different purpose in resource allocation and capacity planning.
Placeholders can be allocated to projects in the same way as named resources. They allow project managers to forecast demand early, even when the specific people who will perform the work are not yet known. This makes it possible to:
Reserve capacity for upcoming work.
Identify potential bottlenecks at team, pool, or role level.
Keep project plans moving while recruitment, assignment, or resource confirmation is still in progress.
It’s important to remember, however, that placeholders are a planning and forecasting tool. They enable you to model demand against available capacity, but at some point they need to be replaced by named resources. Until a placeholder is swapped with a real person, no one is actually assigned to do the work.
Whether you are forecasting role-based, schedule-based, or using a combination of methods, placeholders help bridge the gap between early planning and execution. To ensure delivery, project managers must confirm and assign the correct named resources before the work is due to start.
Resource Placeholders
A Resource Placeholder is the closest proxy to a named resource. It represents a single individual role that you know will exist but is not yet assigned to a specific person.
Capacity: Typically set to 1 headcount, representing a single full-time individual. This can be adjusted (e.g., 0.5 headcount) if the role is expected to be filled by a part-time resource.
Usage: Use a Resource Placeholder when you need to plan for a role that will eventually be filled by a specific individual — such as a new hire or a replacement for an existing resource.
Example: Suppose John D leaves the organisation. You can create a Resource Placeholder called “John D Replacement Hire” to represent the future role. The placeholder can be allocated to the Cloud Migration project straight away, ensuring that project allocations and forecasted spend reflect the planned hire. When the new employee starts, the placeholder can then be replaced with the actual named resource.
Team Placeholders
A Team Placeholder represents a delivery team as a whole. It is a dynamic grouping of the people who belong to that team, and its capacity is automatically calculated from the combined capacity of its members.
Capacity: The capacity is the sum of the capacities of all resources currently assigned to the team. If people join or leave the team, the placeholder’s capacity increases or decreases accordingly.
Usage: Use a Team Placeholder when you know the work will be delivered by a specific delivery team but you don’t yet know exactly which individuals from the team will do the work.
Example: A Project Manager will use a Team Placeholder when indicating a need for a specific team on a project. When allocating the placeholder, the role (e.g. Business Analyst, QA Analyst, Developer) must be specified. The team itself is not associated with any engagement type, as it can include both employees and contractors without distinction.
Important: The capacity of a Team Placeholder cannot be changed manually; it is always system-calculated.
Pool Placeholders
A Pool Placeholder represents a pool of skills or roles — for example, a pool of developers or QA analysts. Unlike team placeholders, the capacity here is defined manually and reflects the available headcount in that pool.
Capacity: Defined as a total headcount for the pool (e.g., if you have 10 developers in the organisation, the Developer Pool capacity can be set to 10). This value doesn’t change automatically; it must be updated if the size of the pool changes.
Usage: Use a Pool Placeholder when you know the type of resource you need (e.g., developer, QA analyst) but not which specific team or individual will do the work. This allows you to allocate demand against a defined pool capacity.
Example: Pool placeholders can be used by project managers during the initial planning of a project. For instance, a project manager might allocate 10 Developer Pool Placeholders to a project. As more information becomes available about which teams these developers will come from, the allocations can be refined — for example, moving them to an Oracle Team Placeholder (5 resources), a Middleware Team Placeholder (2 resources), and a QA Team Placeholder (3 resources). Alternatively, they can also be reassigned directly to named resources once the individuals are identified.
Pool placeholders are also useful during fiscal year planning exercises. They can be set up with an engagement type (e.g. Employee, Contractor) and optional metadata such as region or country. When allocating a Pool Placeholder to a project, you then specify the project role it will fulfil (e.g. Developer, QA Analyst).
Important: The capacity of a Pool Placeholder is defined manually and can be changed at any time to reflect updates in the pool size.