Separate the requirement from its fulfilment
A requirement describes what a role, task or area needs. Fulfilment describes a specific person, material, result and date. Keeping these layers separate allows requirements to change without rewriting an individual's history.
Do not assign everything from job title alone. Temporary duties, substitution and additional authorization can mean that two people with the same title need different material.
Use states that lead to action
Useful states include required, assigned, due, completed, failed, expiring and overdue. Each state should identify who owns the next action.
Colour can improve scanning, but it must not carry the only meaning. Status should also be available as text and derived from dates and completion records.
- requirement derived from a role or task
- person accountable for assignment
- deadline and validity period
- result and pass threshold
- next action after a gap or expiry
Treat the matrix as a view, not a second register
The matrix should be calculated from current roles, requirements and completions. A manually maintained copy becomes a second source of truth that needs reconciliation after every team change.
An export is useful for review or audit, but it becomes a snapshot when generated. Show the export time and filters so an old file is not mistaken for current status.
Questions worth asking
Can a spreadsheet still be used as an export?
Yes. It is useful as a dated, filtered snapshot as long as it is not manually maintained as a second register afterwards.
How often should the matrix be reviewed?
After material changes to roles, procedures or the team, plus a risk-based periodic review. A calendar alone does not replace change-triggered review.