Two levels of the same decision
A role matrix first describes an organisational agreement, then must be checked against real technical permissions. A system may allow an action the person was not authorised to take in the project. Conversely, an agreed decision may fail because access is missing.
Use specific actions instead of broad role names. “Client” does not distinguish the person providing materials from the person responsible for consolidating feedback.
Example matrix for a small client project
| Action | Team member | Project lead | Client contact | Client decision-maker |
|---|---|---|---|---|
| Read internal calculations | Under internal rules | Yes | No | No |
| View a shared draft | Yes | Yes | Yes | Yes |
| Provide material | Yes | Yes | As agreed | As agreed |
| Give feedback | Yes | Yes | Yes | Yes |
| Document the client's decision | No | Assign the outcome | No | Yes |
| End access | According to technical role | Initiate and check | No | No |
A decision needs a defined subject
Add what is being decided to the matrix. Confirming content order does not approve all text, images and technical properties. Keep subject, version and next action together in the project.
When two client contacts give conflicting feedback, the matrix does not resolve the substance automatically. It identifies the role responsible for consolidating it. Without that owner, the delivery team often becomes the unwilling decision-maker.
Four negative tests for technical implementation
Another project
Use a separate test account to open a known URL in another test project. Access must be denied according to the intended boundary.
Internal file
Test a direct download URL. Merely hiding the file from a list is not sufficient access control.
Unauthorised action
Have the responsible technical person test server-side authorisation. A disabled button alone does not prove it.
Revoked access
After revocation, try new access and check existing session behaviour. Consider already downloaded copies separately.
Update the matrix when things change
Staff changes, new subprojects and additional documents can change scope. Update the matrix at these points; an outdated document creates false confidence.
Initially record date, test role, action, expected result and observed result. If they differ, leave that use unapproved until the cause is understood. A completed spreadsheet does not prove the application enforces the rules.
From the guide to the sample project.
Try the steps in the OOKI demo: tasks, client view, time entries and invoice draft with fictional data. No login required.
Try the demo (DE)