What a tracer system needs to survive handover

We designed and piloted a Performance Measurement and Tracer Study system for a technical and vocational training programme. Staff from 25 institutions came through the training. Two institutions ran the full pilot and between them traced 273 graduates, which is enough to say the instrument works and the fieldwork is feasible. The harder question is whether those two institutions are still running the survey next year without us in the room.

Designing the handover into the pilot

A pilot run with full consultant support will usually succeed, because the consultant quietly absorbs each difficulty: chasing missing phone numbers, fixing a skip pattern, cleaning the data, writing the report. The institution sees a system that works and learns less than it could about running one.

We now stage it deliberately. One site moves to institutional lead earlier than is comfortable, with us observing rather than stepping in, and the gaps that appear become the subject of the next coaching session rather than a problem to be hidden. On our pilots the gaps were not about the instrument at all. They were about who held the graduate list, who was permitted to call a graduate, and whose job it became when a trained member of staff was transferred.

Five things that have to be in place

One register, not five spreadsheets. Most institutions already hold graduate data, spread across admissions, examinations and departmental files, with no agreed identifier. Until those are reconciled into one list with one key, each tracer round is close to a fresh data-collection exercise.

A named owner with hours in the workplan. Not a department and not a committee. One post, named in writing, with the survey appearing in that person's annual duties and the time costed. Most of the rest of this list can be put in place quickly. This one needs a decision by somebody senior.

Contact details collected at exit. Graduate phone numbers decay quickly, and much of that decay happens in the months just after graduation, while the institution still has the student in front of it. Two numbers plus a next-of-kin contact collected at exit, and confirmed at certificate collection, do more for traceability than elaborate follow-up later.

A quality routine short enough to actually run. Short and boring tends to outlast comprehensive and abandoned: validation built into the form so that out-of-range entries are caught at the point of entry, a fixed back-check share with the calls logged, and a one-page monthly check that somebody signs.

A use for the data inside the institution. This is the one that decides the rest. Where the only consumer is a donor report, the survey tends to stop when the grant stops. Where the data feeds something the institution needs anyway, a programme review, a board paper, a claim to employers about where its graduates end up, it keeps running because it has become useful.

What this changes about how we build

It changes the sequence. The instrument comes later, not first. The early work is finding out who owns what, which lists exist, what the institution already has to report and to whom, and which of its own questions the data could answer. A tracer system designed around that is usually smaller than the one a consultant would design unprompted, and more likely to still be running in year three.

It also changes what is written at the end. A final report that describes the system is a document. An operating manual, a dated training record, a data dictionary and a named owner are a handover. We treat the second as the deliverable and the first as a by-product.

What to take from this