Massive operations more agile

Sometimes we need to reassign all cases to another interviewer but this is only possible to do up to 20 cases at a time (the same happens for archiving cases).

In very large projects like the one we are working, a typical workload for an interviewer is more than 500 cases. It will be convenient to modify the GUI a little bit to perform massive changes more agile.

For the moment, could you accomplish this via the API?

Thinking about UI changes, what do you think would make the most sense?

  • Increase page size to 50 rows (like Gmail)
  • Allow users to select page size options (e.g., 20 = default, 50, 100, etc.)
  • Something else

Select all option (Page displays 20, but action is applied to all filtered interviewed) with bulk actions (reassign, approve, reject etc)

Nice one. So somewhat like Gmail’s UI?

image

Could you please elaborate on the frequency and reasons for such reassignments? What are the real world circumstances when this is needed?

Both the interviews list and assignment list could benefit from better filtering and (bulk) actions on the filtered items. We have rarely had to re-assign interviews to other interviewers in bulk, but I can imagine situations where someone would have to. We frequently have to re-assign assignments, and they are a pain.

The APIs are great help with this situation, but its a hassle to setup for every survey in a way that the supervisors can directly use and apply them (we setup a shiny app to help with these re-assignments). having this inbuilt as a feature will greatly help.

In a scenario with 15k interviewers the following situations can be very frequent:

  1. When an interviewer resigns, his/her assignments have to be redistributed to other members of the team.
  2. When an interviewer has to be fired because his/her job was not good.
  3. When an interviewer gets sick, his/her assignments have to be redistributed to other members of the team.
  4. When an interviewer is slow (maybe he just joined the collection process), some of his/her assignments have to be redistributed to other members of the team in order to accelerate the field work.
  5. There are other situations.

Hello Vladimir,

in all of the described scenarios you are redistributing assignments/interviews between multiple [other] team members. In that case the supervisor must be able to specify, which ones go to X, which ones go to Y, etc. Presumably they will do it based on proximity to the area of work of the other interviewers, for which they would need to read identifying information and understand how far it is.

Bulk reassign is possible to implement (take everything that is assigned to A and reassign to B), but redistribution makes it more complex and I don’t see how this can be automated in general.

Perhaps you could revisit your decision to assign 500 cases to each interviewer, which is causing this complication?

Dear Sergiy

I think the problem comes from the size of this project, this census is equivalent to deploying 1900 household surveys at the same time.

This project requires 15,000 interviewers managed by 3,000 supervisors, each team has 1 supervisor and 5 interviewers. The census is managed from 304 local offices where they do the re-assignment operations based on the events that happen in the field (new interviewers, sick interviewers or fired interviewers).

For the whole deployment it is better that these decisions take place in the local offices because if they centralized too much everything can be very slow. NSO has the goal of conducting 6.4 million households in 36 days, this project is very expensive (several dozens of million dollars) that’s why they decided to assign 540 interviews from the beginning for each interviewer (15 interviews per day x 36 days = 540). Everything happens very fast during the census.

We can create a massive reassignment routine using the API (in fact we already created it), but this implies centralization because this program is executed by IT people from the NSO headquarters.

Our recommendation is that the SuSo team can study this experience and maybe apply some changes in the user interface in order to better prepare for large deployments and make everything simpler for the end user.

Thanks

1 Like