Every clinical technology project we have seen work well started the same way: one person wanted it. A nurse, a care home manager, a physiotherapist. Without that person there is no project at all, and we have written that the first of the six yeses belongs to the department.
The problem is the next step, and almost nobody takes it: the project remains that person's forever. They are the one who knows how to switch it on, who has the PIN, who knows the scenarios, who remembers to charge it. And when they move on — which in healthcare happens often — the project is handed to nobody. It simply stops.
The test
One sentence, and it needs no consultancy:
Does this work in the week the person who brought it in is on holiday?
If the answer is no, there is no project yet. There is an enthusiast, and an enthusiast is a good and fragile thing.
A harder variant, for services past their first year: does it work on the night shift, over a long weekend, with half the team on agency cover?
The five defences
None is expensive. All are boring, which is why they do not get done.
1. Two trained people per shift, never one. The most effective defence and the most ignored. One person per shift equals zero when that person is absent. And it helps if the second person is not the same second person on every shift.
2. The procedure written where the equipment is. Not in an email from August, not in a shared folder nobody can find. Five lines taped to the cupboard door beat a thirty-page manual — we argued this about logistics.
3. The task attached to a role, not a name. "Ana puts it on charge" is fragile. "Whoever closes the shift puts it on charge" survives Ana leaving. True for charging, for hygiene and for the cupboard key.
4. Training for arrivals, not only for those already there. Initial training is given once, to the team that existed that day. Two years later, half those people were not there. If a new professional's induction does not include this, the project dilutes without anyone deciding anything.
5. A formal owner, with a named deputy. Someone answers for the project, and it is written down who answers when that person is away. It is the difference between a department's project and one person's project.
What we solve, and it is little
Let us be precise, because continuity is easy to sell as a feature.
We solve one thing: the record. When every session is logged, knowledge about what was done stops living in one person's head. Whoever arrives can see what was done, with whom, and what was interrupted. That is knowledge transfer with no meeting required, and it is real.
We do not solve: training, cover, ownership, shifts. None of that is a software feature, and a supplier telling you the platform "guarantees continuity" is selling something only the institution can do.
We also do not solve the hardest part: willingness does not transfer. Someone inheriting a project rarely wants it with the intensity of whoever brought it in. What can be done is lower the cost of keeping it going, so that enthusiasm is not required to continue — only routine.
An alarm signal that is easy to read
If, after six months, all sessions are logged under the same name, the project has one person and no team. It is visible in the log in ten seconds, and that is the moment to act — not a year later, when that person leaves.
In short
- Every project starts with one person, and almost none stops depending on them.
- The test is the holiday one, and the hard version is the night shift on a long weekend.
- Two people per shift, posted procedure, tasks by role, training for arrivals, an owner with a deputy.
- Software does not guarantee continuity. The log transfers knowledge; the rest belongs to the institution.
- If every session has the same name on it, the project has an expiry date.