Skip to main content
PDWare Customer Success Center

Typical Demand and Capacity Workflow

High level view of the typical demand and capacity workflow, from request through delivery.

From Initiation to Delivery - The Demand and Capacity Process

The diagram below illustrates a typical demand and capacity workflow, from request through delivery.

  1. Project Initiation Proposal: First, a project idea or "initiation" proposal is generated, either from a strategy session, a business need, or a regulatory requirement. Often a process step ensures some sort of business intake filter to validate the project request for completeness and business validity. In ResourceFirst, this can be entered as an Initiation project. See the article on Project Intake and Initiation for more.
  2. Review in Portfolio and Plan Roles/Skills Needed on the Project: A portfolio manager (sometimes this is a product owner, process owner, business unit leader, or PMO representative) reviews the request in the context of the appropriate portfolio. The project or program is created, aligned with the appropriate strategy, scored for value/risk, and prioritized/ranked against other projects in the portfolio. The needed skills are determined and the timing of available capacity for those skills is assessed. High level effort forecasts are entered, usually at a skill or role level. A high level financial forecast can be entered as well.

    In ResourceFirst, project requests can be approved by authorized parties on the Initiation page in the Projects area. Initial high level resource skill forecasts can be made on the Assignments page, or on the Assignments tab on the specific project's workspace (accessed by clicking on any project hyperlink on pages that list projects). Once the resource skills forecast for the project has been entered, you can visit the Projects-->Demand page to see the overall demand for projects in the portfolio, and you can update priorities as needed.

    With the above information, the project or program is given an appropriate start date, depending on priority and available capacity. Sometimes tradeoffs are required in order to apply valuable limited resources to the most important work. Scenario simulations may be performed in order to see the impact to the portfolio based on different situations (e.g., staffing, reprioritization, etc.). Once the project is prioritized and given a start date, a project manager is assigned.
  3. Plan Project & Request Named Resources for Near-Term Items: The project manager plans the project at a high level, making sure the effort forecast includes the right skills at the right time. Resource assignment requests are then sent to the resource managers to assign named resources to the needed skills.

    Note: In some organizations, the project managers plan their resources, and the resource managers then review their people's resulting forecast. Any issues can be discussed through conversation. It is vital though, that the resource managers ultimately own the forecast, as they typically have the broadest picture of what their staff will be needed for in the coming weeks. This is especially true in a matrix organization.
  4. Assign Named Resources: The resource manager fills the resource requests with named resources by searching for candidates among their pool and revising the effort forecast for the project. Note: Requests can be set up for auto-approval to speed up the assignment process, but to avoid chaos, this necessitates having the resource/functional managers check the forecast for their staff periodically to make sure people will be available for other needs and aren't being overbooked on multiple projects. See "Understanding the Resource Request Process" for more..
  5. Execute Project & Adjust Resources: The project manager fleshes out the project schedule and manages the project execution, reporting status as required. This step also includes optionally assigning named resources at a task level (ideally within the existing effort forecast windows).

    Reconciling the task-level resource assignments with the high level resource forecast is often a fruitless cause. Project schedules are dynamic and always changing. Managing resources at a low granularity is difficult to do effectively and is often mismanaged. A "good enough" level of resource-to-project allocation, aligned with project phase timelines and milestones, is more easily maintainable and, ironically, often more accurate.  The best way to resolve discrepancies between task level needs and the project's effort forecast is via a simple conversation between the project manager, resource manager, and/or the resource.   

To reiterate: The project manager typically owns the project schedule, but the resource manager generally owns the effort forecast. This is recommended because only the resource manager has a complete picture of the resource's full workload, including projects, base services, and other current and pending activities.

Below is a high level diagram of the project staffing lifecycle.




  • Was this article helpful?