Resource Capacity Matrix

مصفوفة سعة الموارد

tasleemat asset PMO-00.04 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 00: Program and Portfolio Management

Sizing Tier Requirements

Tier 1

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-00.04 ./completed_data.json

Template Markdown (Bilingual)

<!--  
LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

The resource capacity matrix shows whether the plan is feasible in terms of the
people available to carry it out. It compares what the programme or project
needs against what exists, and the difference is the thing worth reading: a
plan that requires more capacity than is available is not a plan that needs
more effort, it is a plan that cannot be executed as written.

The intent behind separating demand from supply is that they are gathered from
different places and are therefore rarely reconciled by accident. Demand comes
from the schedule and the scope, supply comes from the resourcing plan and the
organisation's actual shape, and nobody reconciles the two until a matrix like
this makes the gap visible. The Gap column is therefore the one the reader
cares about, and a matrix that records only the totals has omitted the only
figure that matters.

Alignment: the resource capacity matrix should be aligned and consistent with
the following documents: Portfolio roadmap, Program charter, Project management
plan, Resource breakdown structure, Procurement plan.

Writing guidance:

*   State the unit of capacity once and use it throughout, whether that is
    person-days, full-time equivalents, or hours per period. A matrix whose
    rows use different units cannot be added up, and the total at the bottom
    is then arithmetically meaningless rather than merely approximate.

*   Record capacity per period, not in total. A resource with a thousand
    person-days available who is fully committed in the month the work is
    needed has no capacity at all, and a total figure hides exactly that.

*   Record the demand from the plan, not from what the team currently is. The
    demand column is what the schedule and scope require; the supply column is
    what exists. Recording the same number in both columns is the single most
    common way a capacity matrix comes to be wrong, because it makes the
    matrix agree with the plan rather than with reality.

*   Record named constraints as consequences, not as adjectives. "Test
    automation is a single point of failure because one person holds it" is
    actionable; "test automation is a risk" is not.

*   Where a gap is covered by a contractor or a shared resource, record the
    contract or agreement that covers it. A gap filled on the understanding
    that someone will help is not covered, and the difference shows up the week
    the help is needed elsewhere.

Tailoring Notes:

*   The matrix may be maintained at portfolio level across all initiatives, or
    at program level across the components, or for a single project. The form
    should say which, because a portfolio matrix is used to decide between
    initiatives and a project matrix is used to decide whether one plan is
    credible.

*   Where the organisation runs a resourcing tool, the matrix may be an
    extract rather than the source of truth. Record that, so a reader does not
    treat a stale extract as current.

*   Add or remove rows as needed. Where a role is filled by more than one
    person, record the role once and note the split in the notes column, since
    a row per person hides the total capacity of the role.

*   The matrix may be maintained by a resourcing or workforce planning
    function, in which case cross-reference it rather than duplicating the
    supply side.

Column guidance, by column:

Capacity by resource:

*   **ID:** The identifier for the resource role, used in the demand and the
    gap sections so the two can be compared row against row.

*   **Resource Role or Team:** The role or team, named as the work requires it
    rather than as the organisation chart draws it. A matrix organised by
    existing departments cannot show a gap, because it only ever lists what is
    already there.

*   **Period:** The period the row covers, using the same periods throughout
    the matrix and matching those of the schedule it is compared against.

*   **Total Available:** The capacity that exists in the period, before any
    allocation, stated in the unit declared for the matrix.

*   **Allocated:** The capacity already committed elsewhere in the portfolio.
    This is the column most often left out, and without it the available
    figure is the total, which is not what the project can use.

*   **Remaining:** What is left after allocation, which is the figure the
    planner actually has.

*   **Constraints or Single Points of Failure:** What limits this resource, such
    as a location, a qualification held by one person, a licence, or a tool
    only one person can operate. Record the consequence rather than the
    adjective.

*   **Notes:** Anything that changes how the row should be read, such as a
    known vacancy, a planned leave, or a commitment shared with another
    portfolio.

Demand rows:

*   **ID:** The resource role the demand is for, matching the ID used above.

*   **Required Capacity:** What the scope and schedule require in the period.
    Record the figure the plan was built on rather than the figure currently
    being achieved, since the second is a consequence of the first being wrong.

*   **Source of Demand:** Which part of the plan generates it, such as a
    specific deliverable or work package. A demand that cannot be traced to
    something in the plan cannot be challenged, and demands that cannot be
    challenged only ever grow.

*   **Period:** The period the demand falls in.

*   **Priority:** Whether the demand is essential, or could be deferred or
    descoped. Without a priority a gap has no remedy, because the only
    available responses are to add capacity, move the work, or reduce it, and
    the matrix does not say which is acceptable.

Gap analysis rows:

*   **Resource Role:** The role the gap applies to.

*   **Gap:** The difference between required and remaining, stated as a number
    and signed so a surplus is not read as a shortfall.

*   **Period:** The period the gap falls in.

*   **Resolution Planned:** How the gap will be closed, whether by recruitment,
    by a contractor, by moving work between periods, or by reducing scope.

*   **Resolution Owner:** Who is accountable for closing it. A gap with a
    planned resolution and no owner is a gap that is being wished away, and it
    is the most common way a capacity matrix comes to be relied upon.

*   **Resolution Date:** By when the resolution is expected to be in place,
    which is what tells the reader whether the plan is still feasible.

Contingency rows:

*   **Resource Role:** The role the contingency applies to.

*   **Contingency Type:** Whether the buffer is in capacity, in time, or in
    scope. The three are not interchangeable: time contingency can be spent
    once, capacity contingency can be spent on anything, and scope
    contingency reduces the deliverable.

*   **Contingency Amount:** The size of the buffer, in the declared unit.

*   **How It Would Be Used:** What it protects, so that a buffer cannot be
    quietly consumed on something it was not held for.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Organization_Unit}} - {{Planning_Period}}</h2>
<h1 dir="ltr" align="center">RESOURCE CAPACITY MATRIX</h1>

| **Date Prepared:** {{Current_Date}} | **Program Manager:** {{Program_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Matrix Basis
<!-- What this matrix covers, in what unit, and over which periods. Record the
 unit once and use it throughout: a matrix whose rows use different units
 cannot be added up, and a total is then arithmetically meaningless rather than
 merely approximate. Record the level the matrix is maintained at, because a
 portfolio matrix is used to decide between initiatives while a project matrix
 is used to decide whether a single plan is credible. And record whether this
 is the source of truth or an extract from a resourcing tool, so a reader does
 not treat a stale extract as current. -->

**Matrix Scope and Level:** [ Add details... ]

**Capacity Unit of Measure:** [ Add details... ]

**Periods Covered:** [ Add details... ]

**Source of Truth or Extract:** [ Add details... ]

**Matrix Owner:** [ Add details... ]

**Last Updated:** [ Add details... ]

---

## 2. Capacity by Resource
<!-- What exists, in what unit, in which period. The Allocated column is the one
 most often left out, and without it the available figure is the total, which
 is not what the project can use. Record capacity per period rather than in
 total: a resource with a thousand person-days available who is fully
 committed in the month the work is needed has no capacity at all, and a total
 figure hides exactly that. Record constraints as consequences, not as
 adjectives; "test automation is a single point of failure because one person
 holds it" can be acted on, and "test automation is a risk" cannot. Where a
 role is filled by more than one person, record the role once and note the
 split, since a row per person hides the total capacity of the role. Add or
 remove rows as needed. -->

| ID | Resource Role or Team | Period | Total Available | Allocated | Remaining | Constraints or Single Points of Failure | Notes |
| :---: | :--- | :---: | ---: | ---: | ---: | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 3. Demand by Resource
<!-- What the plan requires, which is a different number from what is
 currently being achieved. Record the figure the plan was built on rather than
 the figure being achieved, since the second is a consequence of the first
 being wrong. Record the source of the demand so it can be traced to a
 deliverable or a work package; a demand that cannot be traced to something in
 the plan cannot be challenged, and demands that cannot be challenged only ever
 grow. Record a priority, because without one a gap has no remedy, since the
 available responses are to add capacity, move the work, or reduce it, and
 nothing in the matrix says which is acceptable here. Add or remove rows as
 needed. -->

| ID | Resource Role | Period | Required Capacity | Source of Demand | Priority |
| :---: | :--- | :---: | ---: | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 4. Gap Analysis
<!-- The difference between what is required and what is remaining, which is
 the only figure in the matrix the reader is looking for. State it as a signed
 number so a surplus is not read as a shortfall. Record a planned resolution
 and, separately, an owner for it: a gap with a resolution and no owner is a
 gap being wished away, and it is the most common way a capacity matrix comes
 to be relied upon after it has already been superseded. The resolution date is
 what tells the reader whether the plan is still feasible, so record it rather
 than leaving the row open. Add or remove rows as needed. -->

| Resource Role | Gap | Period | Resolution Planned | Resolution Owner | Resolution Date |
| :--- | ---: | :---: | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 5. Contingency
<!-- What the plan holds in reserve, and what that reserve protects. The three
 kinds of contingency are not interchangeable: time contingency can be spent
 once, capacity contingency can be spent on anything, and scope contingency
 reduces the deliverable. Record which kind each buffer is, because a plan that
 holds no scope contingency and states only that it has float is a plan whose
 contingency is the work being cut. Record what each buffer protects so that it
 cannot be quietly consumed on something it was not held for. Add or remove
 rows as needed. -->

| Resource Role | Contingency Type | Contingency Amount | How It Would Be Used |
| :--- | :--- | ---: | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 6. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Resource Planning Lead** | {{Resource_Planning_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **Program Manager** | {{Program_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **PMO Director** | {{PMO_Director_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> Resource Capacity Matrix | <strong>Ref:</strong> PMO-00.04 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Resource Capacity Matrix

Document Reference: PMO-00.04

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Resource Capacity Matrix in alignment with the Tasleemat framework.

1. What?

A formal Tasleemat-aligned project document known as the Resource Capacity Matrix, showing whether the plan is feasible in terms of the people available to carry it out.

It records the basis of the matrix and its unit of measure, the capacity that exists by role and period with what is already allocated elsewhere, the demand the scope and schedule create with the source and priority of each, the gap between the two with how each gap will be closed and by whom, and the contingency the plan holds and what that contingency protects.

2. Why?

Because demand and supply are gathered from different places and are therefore never reconciled by accident. Demand comes from the schedule and the scope, supply comes from the resourcing plan and the organisation's actual shape, and nobody sets the two against each other until a matrix like this makes the gap visible. The Gap column is the one the reader is looking for, so a matrix that records only totals has omitted the only figure that matters.

3. When?

This artifact is prepared at the PROGRAM AND PORTFOLIO MANAGEMENT Process Group, and re-reconciled whenever the schedule changes materially or the organisation is restructured. It is a recurring reconciliation rather than a document produced once, because capacity is reallocated continuously and a matrix that is not refreshed describes an organisation that no longer exists.

4. Who?

Responsibilities: Owned by the Program Manager and reconciled with the resource or workforce planning function that holds the supply side. Signed by the PMO and by the finance business partner, since a gap closed by a contractor is a cost change and should not be agreed without someone who can see the cost.

Tailoring Tips

The matrix may be maintained at portfolio level across all initiatives, or at program level across the components, or for a single project. The form should say which, because a portfolio matrix is used to decide between initiatives and a project matrix is used to decide whether one plan is credible.
Where the organisation runs a resourcing tool, the matrix may be an extract rather than the source of truth. Record that, so a reader does not treat a stale extract as current.
Add or remove rows as needed. Where a role is filled by more than one person, record the role once and note the split in the notes column, since a row per person hides the total capacity of the role.
The matrix may be maintained by a resourcing or workforce planning function, in which case cross-reference it rather than duplicating the supply side.
The contingency section may be omitted where the organisation holds contingency centrally, but the form should say so explicitly rather than leaving a reader to assume the plan holds none.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Portfolio Roadmap (PMO-00.01)
- Program Charter (PMO-00.02)
- Organizational Staffing Budgets
Optional / Contextual:
- Resource Management Plans (PMO-04.06.01)
- Resource Requirements (PMO-04.06.02)

2. Downstream Dependents

Mandatory:
- Project Resource Management Plans (PMO-04.06.01)
- Project Schedules (PMO-04.03.08)
Optional / Contextual:
- Responsibility Assignment Matrix / RAM (PMO-04.06.04)
- Procurement Strategy (PMO-04.09.02)

5. How?

To accurately and professionally complete the RESOURCE CAPACITY MATRIX, the responsible party must populate the following sections based on the project context (ensure parameters.md is referenced for global project variables):

Matrix Scope and Level: What this matrix covers and at what level it is maintained, whether portfolio-wide across initiatives, program-wide across components, or for a single project. The level decides what the matrix is used to decide: a portfolio matrix decides between initiatives, a project matrix decides whether one plan is credible, and reading either as the other produces a confident wrong answer.
Capacity Unit of Measure: The unit used for every figure in the matrix, whether person-days, full-time equivalents, or hours per period. State it once and use it throughout: a matrix whose rows use different units cannot be added up, and the total at the foot of it is then arithmetically meaningless rather than merely approximate.
Periods Covered: The periods the matrix covers, matching those of the schedule it is compared against. Where the matrix is annual and the schedule is weekly, the comparison has to be done by hand every time and is therefore not done, which is how a quarterly shortfall survives to become a delivery failure.
Source of Truth or Extract: Whether this matrix is the authoritative record or an extract from a resourcing tool. Record which, because a reader who treats a stale extract as current will plan against capacity that was reallocated weeks ago, and the error surfaces only when the work cannot be staffed.
Matrix Owner: The single role accountable for the matrix as a whole, which is normally not the owner of any one resource in it. Where this is blank, the matrix has contributors but nobody who notices that a row has not been updated since the reorganisation.
Last Updated: The date the matrix was last reconciled against the plan, and against which version of the schedule. Without it a reader cannot tell a current matrix from an abandoned one, and the two are indistinguishable on the page.
ID: The identifier for the resource role, used in the demand and gap sections so the three can be compared row against row. Without a shared identifier the comparison is done by eye, and two similarly named roles are the ones most often confused.
Resource Role or Team: The role or team, named as the work requires it rather than as the organisation chart draws it. A matrix organised by existing departments can never show a gap, because it only ever lists what is already there, and the absence of a needed capability reads as its absence from the plan rather than from the organisation.
Period: The period the row covers, using the same periods throughout the matrix. Capacity recorded per period rather than in total is what makes the matrix usable, because a resource with a thousand person-days available who is fully committed in the month the work is needed has no capacity at all.
Total Available: The capacity that exists in the period, before any allocation, in the unit declared for the matrix. This is a figure about the organisation rather than about the project, and recording it here is what allows the reader to see how much of it is actually available.
Allocated: The capacity already committed elsewhere in the portfolio. This is the column most often left out, and without it the available figure is the total, which is not what the project can use. It is also the column that reveals a resource being shared between initiatives without either owner knowing.
Remaining: What is left after allocation, which is the figure the planner actually has. Where this is negative, the matrix has found a real problem; where it is silently recorded as zero because nobody wanted to write a negative number, the problem has been hidden instead of solved.
Constraints or Single Points of Failure: What limits this resource: a location, a qualification held by one person, a licence, a tool only one person can operate, or a notice period. Record the consequence rather than the adjective, because "test automation is a single point of failure because one person holds it" can be acted on, while "test automation is a risk" cannot.
Notes: Anything that changes how the row should be read, such as a known vacancy, planned leave, or a resource shared with another portfolio. Where a role is filled by more than one person, record the role once and note the split here, since a row per person hides the total capacity of the role.
ID: The resource role the demand is for, matching the ID used in the capacity section so the two can be set against each other.
Resource Role: The role the demand falls on, using the same naming as the capacity section. The two must be the same list, or the comparison in the gap section silently excludes roles that appear in only one of them, which are usually the ones in trouble.
Period: The period the demand falls in. A demand recorded with no period cannot be compared with a capacity figure that has one, and is therefore dropped from the comparison without anyone deciding to drop it.
Required Capacity: What the scope and schedule require in the period. Record the figure the plan was built on rather than the figure currently being achieved, since the second is a consequence of the first being wrong and reporting it back as the requirement makes the shortfall disappear from the plan.
Source of Demand: Which part of the plan generates it, such as a named deliverable, work package, or activity. A demand that cannot be traced to something in the plan cannot be challenged, and demands that cannot be challenged only ever grow.
Priority: Whether the demand is essential, or could be deferred or descoped. Without a priority a gap has no remedy, because the available responses are to add capacity, move the work, or reduce it, and nothing in the matrix says which of those the programme would accept.
Resource Role: The role the gap applies to, using the same naming as the sections above. Where a role appears in the demand but not the capacity, the gap is the whole requirement rather than a shortfall, and that case is worth distinguishing because it is a different problem.
Gap: The difference between required and remaining, stated as a signed number so that a surplus is not read as a shortfall. This is the figure the whole matrix exists to produce, and a matrix that records only the totals has omitted the only number anyone reads.
Period: The period the gap falls in. A gap in a period with no demand in it is a different problem from a gap in a period the work needs, and reporting both as "a gap" sends the reader looking for the wrong remedy.
Resolution Planned: How the gap will be closed: recruitment, a contractor, moving work between periods, reducing scope, or accepting the risk. Where the gap is covered by a contractor or a shared resource, record the contract or agreement that covers it, because a gap filled on the understanding that someone will help is not covered at all.
Resolution Owner: Who is accountable for closing the gap. A gap with a planned resolution and no owner is a gap being wished away, and it is the most common way a capacity matrix comes to be relied upon long after it was last true.
Resolution Date: By when the resolution is expected to be in place. This is what tells the reader whether the plan is still feasible, so record it rather than leaving the row open, and where the date has passed without resolution, escalate rather than moving the date.
Resource Role: The role the contingency applies to, or "plan" where the buffer is held across all roles rather than against one.
Contingency Type: Whether the buffer is in capacity, in time, or in scope. The three are not interchangeable: time contingency can be spent once, capacity contingency can be spent on anything, and scope contingency reduces the deliverable. A plan that holds no scope contingency and states only that it has float is a plan whose contingency is the work being cut.
Contingency Amount: The size of the buffer, in the declared unit. Record it as a figure rather than a percentage, because a percentage of a demand that was never reconciled produces a number that looks precise and is not.
How It Would Be Used: What the buffer protects, recorded so it cannot be quietly consumed on something it was not held for. A contingency with no stated use is the first thing cut in a difficult month, which is precisely the month it was held for.

📥 Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 00_04_Resource_Capacity_Matrix_Example.md

LLM Generation Prompt & Agent Instructions

RESOURCE CAPACITY MATRIX - LLM GENERATION GUIDE

System Prompt / Instructions: This document serves as the detailed instruction set for generating the RESOURCE CAPACITY MATRIX. When asked to populate this form, use the guidance provided for each section below to accurately generate the required content. Reference parameters.md for global project variables.

Context & Definition: The resource capacity matrix shows whether the plan is feasible in terms of the people available to carry it out. It compares what the programme or project needs against what exists, and the difference is the thing worth reading: a plan that requires more capacity than is available is not a plan that needs more effort, it is a plan that cannot be executed as written.

Alignment: This resource capacity matrix must be consistent with: Portfolio roadmap, Program charter, Project management plan, Resource breakdown structure, Procurement plan.

Matrix Scope and Level

Instruction: What this matrix covers and at what level it is maintained, whether portfolio-wide across initiatives, program-wide across components, or for a single project. The level decides what the matrix is used to decide: a portfolio matrix decides between initiatives, a project matrix decides whether one plan is credible, and reading either as the other produces a confident wrong answer.