Every programme changes its questions — a funder adds a requirement, a pilot exposes a bad item. Versioning a question instead of overwriting it keeps the responses you already have, starts a clean series for the new wording, and makes the revision visible in any report that spans both.
This chapter resolves check 01 Self-driven of the eight checks.
A programme manager at a job-training nonprofit notices, in her second year, that one question on the intake form is doing no work. Everyone answers it the same way and nobody has ever used the answer. She wants to swap it for a question about childcare, which is what participants keep raising in person. Someone in the Monday meeting says: last time we edited a live form, the numbers moved and we lost two weeks working out why. The question stays.
It is still there in year four. Nothing broke, and that is the problem — the team is collecting careful, consistent answers to a question that stopped mattering in year two.
You add a new version of the question instead of writing over the old one. The old wording keeps the answers already given to it. The new wording starts a fresh run from the day of the change. And any report covering both periods says, on the page, that the wording changed partway through.
The mistake is editing a question in place. Two different questions then share one column, and the trend you look at afterwards is partly measuring your edit rather than your participants.
Sometimes a supplier is the block, and a reworded question becomes a ticket that lands a quarter late. Sometimes it is an internal queue. Most often nobody blocks anything: the team will not risk it, because last time went badly. That failure survives for years, because from outside it looks like discipline.
Not every edit is risky. Sort the change into one of three groups first — only the third needs care.
| The change | What it looks like | What to do |
|---|---|---|
| You add something new | A question this year's group is asked and last year's never saw. | Just add it. Earlier groups show as "not asked" — never as blanks or zeros. |
| You tidy the wording | A typo. "Please describe" becomes "Describe". | Safe to edit in place. Log it, so a later reader can see the words moved. |
| You change what you are asking | A 1–5 scale becomes 1–7. The options change. The question asks a different thing. | Keep both versions. Old wording holds its answers, new wording starts its own run, reports covering both say so. |
The only judgement call is between the second row and the third, and one test settles it: would someone plausibly answer differently because of this edit? If yes, it is row three, however small the edit looks. Adding the word "not" is three characters and reverses the whole question.
An illustration. The programme and the numbers are made up.
A workforce programme has asked the same thing since 2024: "How confident are you that you could pass a technical interview?", on a 1–5 scale. In mid-2026 the team decides 1–5 is too blunt, moves to 1–7, and adds a new question about interview practice.
Done badly, the average jumps from 3.4 to 4.6 and the programme reports a big gain in confidence. The gain is not real — it is the wider scale. A 7 was not available before. Done well:
The programme can still say something useful across the whole period: the direction of travel inside each run, and — for one figure spanning both — the share of people who picked one of the top two options. That works on a 1–5 and a 1–7 scale, because it describes where an answer sits rather than what number it was.
Self-driven does not mean anyone can do anything. It means the limits are rules your team wrote, not a queue your team waits in:
Agree the list before you need it. Teams freeze not for want of permission but because nobody said which changes were safe, so every change felt like a gamble.
And plainly: none of this asks you to understand how AI works, or to write a prompt, or to involve anyone technical. Changing a question is an ordinary programme decision, made by the person closest to the participants, on an ordinary Tuesday.
You can run the whole method by hand, and it is worth doing once, because it shows what a tool is for.
That is a complete method. For one programme with one person keeping the log, it works.
It breaks on repetition, in three predictable places.
The log drifts from the form. Someone makes a quick fix on Friday, means to log it Monday, and does not. Six months on, the log describes a form that no longer exists and nobody trusts it enough to check.
The person who kept it leaves. Their successor inherits a tab of abbreviations and cannot tell which wording was live in June.
The note is left out of the one report that needed it. Twelve reports go out fine. The thirteenth is the board pack, built in a hurry by someone who did not know the log existed, and it draws one confidence line across the scale change.
This is the narrow thing a system does. Sopact Sense keeps the version attached to the question itself rather than in a separate document, so answers stay with the wording they were given to, and a report crossing a change carries the note because the change is part of the record — not because somebody remembered.
Use: A cycle already running, one change you genuinely want — a rescaled or reworded question — and one brand-new question.
Pass: Someone on your team makes the change, with no ticket. Answers already collected stay with the old wording. A report spanning the change says so instead of averaging across it. The new question reads as "not asked" for earlier groups. The edit is logged with a name and a date.
Fail: The change needs a supplier or another department. Or it goes through quietly and the trend moves with nothing telling you the question moved.
Do this on a live cycle, not a demo account. A demo has no history to break, which is what this check is about.
Yes for new questions and small wording fixes. For a real change of meaning, only if both versions are kept. Ask whether someone might answer differently because of your edit. If they might, old and new wording must stay separable — or next year's trend is partly a picture of your edit.
Changing the range of a scale, changing the answer options, flipping a question so agreeing means the opposite, or rewording it to ask about something else. The size of the edit is irrelevant — adding "not" is three characters and turns the question inside out.
Do not average across it. Show each run separately. If you need one figure covering both, use the share of people who chose one of the top two options. That works on a 1–5 and a 1–7 scale, because it describes where an answer sits rather than what number it was.
Less often than the opposite does. The usual failure is too few changes, not too many: a team afraid of breaking the trend stops improving its questions and spends years collecting the wrong thing consistently. A short permissions list and a change log cover the real risk.
Three things: how you recognise a person from one round to the next, your consent wording, and any rule about hiding results for very small groups. Each can undo work downstream in ways nobody notices for months, so each belongs behind a written, dated decision.
No. Changing a question is a programme decision, and the right person to make it is the one who talks to participants. You do not need to know how the analysis works, and you do not need to write anything resembling a prompt. If a change needs a specialist, it will not happen.
The frozen form never announces itself. No error message, no bad report. The forms go out, the answers come back, the charts hold their shape — and in the gap between what the programme now cares about and what the form still asks, the team quietly stops learning anything new.
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Try it in Sopact →
