Office workers spend 4 hours and 38 minutes a week redoing work that’s already been done. That’s the global average from Asana’s Anatomy of Work study of more than 10,000 workers. In quant ops, that rework has a more familiar name: last wave.
Quant ops rework keeps coming back for one simple reason. What a team learns in one wave isn’t kept where the next wave starts. The fix happened and the lesson got lost on the way to the next build.
What Quant Ops Rework Looks Like on a Tracker
A tracker is a survey you run again and again, monthly, quarterly or yearly, with the same questions, so the client can see what’s changing over time. Each round is called a wave. In theory, every wave should be easier than the last.
On paper, it is. The questionnaire is approved. The script exists. The tables were built last time.
Then the same jobs come back:
- A routing bug fixed in Wave 8 turns up again in Wave 9.
- Tables get rebuilt because nobody can say which version the client signed off.
- Coded open answers get checked one by one, again, because last wave’s coding decisions live in someone’s inbox.
- The whole survey gets re-tested “just to be safe.”
Why Repeat Work Is a Memory Problem
Your team didn’t just forget how to do the job. The project forgot what it learned.
Every wave produces small decisions. A new brand goes in at code 8. A filter gets fixed mid-field. The client asks for “past month” instead of “past three months,” then changes their mind in week two. Each decision makes sense on the day.
Then it gets stored somewhere in a programmer’s memory, or an email thread. It’s a file called something like: Tracker_W9_FINAL_v3_use_this_one.xlsx. We’ve all opened that file or named it.
The next wave starts from the script. But the script doesn’t carry the story behind it. So the team either rebuilds the story or works without it.
People moving on makes this worse. Greenbook lists turnover as the first way insights teams lose knowledge: when someone leaves or changes role, their projects and know-how go with them. A tracker that runs for five years will likely see more than one project manager.
That’s the logic we work from in our Bright MR and Kalever practice. A wave isn’t finished when it closes in field. It’s finished when what it learned is written down where the next wave will look first.
The “Just to Be Safe” Tax
This is the part buyers rarely see.
A full re-test of a long tracker means re-running every route, every quota and every piece of piped text. Often the real changes touch three questions. Checking everything twice is what teams do when they can’t see what changed.
For a research director, that shows up in three places:
- Margin. A repeat tracker should get cheaper to run with every wave. Your client won’t pay for Wave 9 like a new study. When the work doesn’t shrink, the gap comes out of your margin.
- Timing. Re-checks land at the end, right before field, when the calendar has no slack left.
- Risk that stays. Re-testing finds errors. It doesn’t explain where they came from. Without that story, the same fix gets made again next wave.
There’s a fourth cost, and it’s the one we’d put on every project plan. If Wave 10 depends on one person being in the office that week, the tracker has a single point of failure. Holidays count.
Five Questions to Ask Before Your Next Wave
You don’t need to read a script to spot this. Ask:
- Where does the list of last wave’s changes live, and could someone new find it in five minutes?
- Was every mid-field fix also made in the master script?
- Has the person building the next wave read the change log before starting?
- Which checks are we repeating because we know something changed, and which because we can’t tell?
- If our main programmer left tomorrow, which wave would we struggle to rebuild?
Where the Memory Problem Shows Up Hardest
Most teams get away with a thin record for a while. The person who remembers is still around, and the tracker stays where it is.
Then the tracker changes hands. Or it changes platform. That’s when everything nobody wrote down becomes visible at once, usually in the first wave that doesn’t match the last.
Contract renewal season is close. A lot of trackers are about to find out how much they remember.
Quick Definitions
- Tracker (or tracking study): a survey repeated at regular intervals with the same questions, so you can see how answers change over time.
- Wave: one round of a tracker. Wave 1 is the first run, Wave 2 the next, and so on.
- Trend data: the results of all waves lined up side by side. It’s the reason a tracker exists.
- Script: the programmed version of the questionnaire that respondents take online.
- Change log: a running list of every change made to a tracker, wave by wave, and why.
- Re-QA: re-testing the whole survey from scratch because nobody can say what changed.
Where to Go Next
If your tracker’s waves have stopped matching and nobody can say why, start with Nobody Changed the Tracker. So Why Doesn’t Wave 7 Match Wave 1? It covers the seven script changes that break a tracker between waves.
For the record-keeping side, read Nobody Reads the Tracker Change Log. Including the Person Who Wrote It. It includes a five-line change log template your team can use on the next wave.
And if you’d like one email a month with pieces like this, sign up for the CodexMR newsletter.
