By Ritvars Mētra, Founder of ReadinessCompassOpen almost any programme RAID log and the risks are recognisable: integration complexity, supplier dependency, environment availability, data migration volume, budget contingency.
Somewhere near the bottom, in amber, one line reads “User adoption risk — Medium — Owner: Change Manager — Mitigation: comms and training plan in place”. It has said that for eleven months.
Why that line never moves
It is not a risk. It is a category. It has no trigger, no measurable consequence, no threshold at which anything happens, and a mitigation that would exist regardless.
A risk that cannot change status is inert. It will be reviewed monthly, remain amber, and be closed at go-live on the grounds that go-live happened — which tells you nothing about whether the risk materialised.
Write people risk the way delivery risk is written
| Instead of | Write |
|---|---|
| User adoption risk | If fewer than 8 of 12 order clerks can complete a standard order unaided by 14 October, day-one throughput drops below the level needed to clear the daily queue |
| Manager engagement risk | Three of nine line managers have not attended a briefing. Their teams cover 40% of transaction volume |
| Capacity risk | Finance is closing year-end in the fortnight before go-live and has not identified who covers training |
| Resistance in operations | The night shift has had no session at a time they work. 60 people have received no briefing at all |
Each right-hand entry has the properties a delivery risk has: a number, a date, a named population and a stated consequence. It can go green when the condition is met, and it can be escalated when it is not, because there is something to escalate.
That specificity is also what gets people risk taken seriously in a room full of engineers. “Adoption is amber” invites a shrug; “60 night-shift staff have had no briefing” invites a decision.
The assumptions column is where the real exposure sits
RAID logs are usually worked hard on risks and issues, lightly on dependencies, and barely at all on assumptions. For people risk, assumptions are where almost everything dangerous lives, because they are the things nobody thought needed checking.
Typical unstated assumptions on a system programme:
- That managers will release super users for the time agreed — usually agreed verbally, months earlier, by someone who has since changed role.
- That people will have practice time between training and go-live.
- That the training environment will contain usable data.
- That nothing else significant lands on these teams in the same quarter.
- That the process owners who signed the design still agree with it.
Each of those is testable in a phone call, and each becomes an expensive issue if it turns out to be false in week minus two. Moving them from unstated assumption to logged assumption with an owner and a validation date is among the cheapest risk work available on a programme.
Three habits
- Give every people risk a threshold and a date. If it cannot be expressed that way, it is a concern rather than a risk, and it belongs in a different conversation.
- Put the consequence in operational terms. Not “reduced adoption” but “orders not shipped on day two”. A steering committee responds to the second.
- Own it in the business, not in the change team. A risk about whether finance has capacity should be owned by finance. Change-team ownership of a business risk is how it stays amber for eleven months.
None of this requires a separate people-risk process. It requires writing people risk to the same standard the programme already applies to everything else — which is usually the only reason it gets less attention.
If you want a structure for this, the Transformation RAID Log guide sets out the four categories and how to run them, and the Adoption Risk Hub has related material on making people risk visible to delivery governance.