Questionnaires change during fieldwork more often than plans admit. A question confuses respondents, a choice list lacks a common answer, or a translation turns out to be wrong. Changing the questionnaire is sometimes the right decision. Changing it without control makes interviews from before and after the change hard to compare.
Principles
- Number every version. Each version interviewers use has its own number, and every interview records which version it used.
- Freeze what is in the field. Do not edit a version while it is in use; make a new version instead.
- Keep codes stable. Never reuse a choice code or variable name for a different meaning. Add new codes for new options and retire old ones, so that a code means the same thing in every version.
- Keep a change log. For each version, record what changed, why, who approved it and from which date it was used.
- Re-test and brief. Test the new version in every language, and brief interviewers before they use it.
How changes affect comparability
| Change | Effect on comparability |
|---|---|
| Fixing a typing error or clarifying an instruction | Usually low risk; record it, because a clarification can also change how a question is answered |
| Adding an answer option, for example one often written in under “Other” | Can change how answers are distributed: some respondents who chose “Other” or a neighbouring option may now choose the new one. Keep existing codes unchanged, compare shares before and after with care and record when the change took effect |
| Changing a question's wording or reference period | Answers before and after may not be comparable; treat it as a new question or flag it in analysis |
| Changing skip logic | Changes who is asked; check how earlier interviews are interpreted |
| Reusing a code or variable name for something new | Unsafe: earlier and later answers become indistinguishable |
Interviews already under way
Interviewers working offline may still hold the earlier version. Decide whether interviews already started may be finished on that version, and make sure every interview records its version so that analysts can tell them apart.
Analysis across versions
Analysts should be able to combine versions where questions are unchanged and separate them where they are not. Variable names that persist across versions, the version number in every record and the change log together make this possible.
An example
After the first week, many respondents answer “Other” for their main source of drinking water and specify “water vendor”. The team adds “Water vendor” as a new option with a new code, releases it as version 2 and records the change in the log. In analysis, earlier “Other: water vendor” answers are recoded to the new option, and the original text is kept. Shares before and after the change are still not directly comparable: before version 2, some respondents may have chosen a neighbouring option instead of writing in “water vendor”.
Limitations
Version control keeps changes traceable; it does not make a changed question comparable. Substantive changes are best made before fieldwork, which is why thorough pretesting pays off.