Meeting notes - November 1st 2024

[Chris-ECE]

Reviewing the Overarching Processes without dedicated sections containing explanatory text

It was agreed we should not move all the Overarching Processes (OPs) to GAMSO, as some had suggested in the feedback received.

It was also agreed to rename some of the OPs as follows, removing the word “management” to make them distinct from GAMSO:

• Quality management -> Quality assurance
• Metadata management (says the same)
• Data management (stays the same)
• Process data management -> Process data acquisition and review
• Knowledge management -> Knowledge sharing
• Provider management -> Provider liaison

Of the 6 overarching processes listed in bullet points (which contain a small amount of explanatory text), 3 of these have dedicated sections containing explanatory text, but the following do not:

• Knowledge Management
• Process Data Management
• Provider Management

Edgardo suggested that all 6 OPs should have the same level of relevance (either be elaborated to a similar extent, or removed).

Knowledge Management

InKyung wasn’t sure why the Knowledge Management OP is separate from Process Data Management OP. Edgardo suggested it’s more about knowledge sharing and ensuring processes are well-documented and passed down when staff turn over and are replaced. InKyung suggested knowledge sharing is not part of the production process itself (GAMSO has a “Manage Information and Knowledge” activity), while generation of documentation would sit under Process Data Management rather than Knowledge Management.
Edgardo suggested that this OP refers to operations manuals/guidelines that explain how to operate the processes (documentation of the code, etc.). You document as you go, which is why this process is overarching. InKyung suggested we need more explanation of Knowledge Management, to make its role clear.
InKyung asked if creation of the documentation happens in the Design phase, but might be updated as an OP. Edgardo suggested that it is not only the IT that would be documented, but also the interviewer’s manual and supervisor’s manual, etc. (They have to be preserved and updated, with versioning.)

Action: Juan offered to draft some text for Knowledge Management

Process Data Management

There was discussion about what the Process Data Management OP is referring to.

Juan suggested it might include paradata logs, but beyond execution of software/code you also have control data during fieldwork to say if you need to revisit a particular location, so the idea can be more abstract.
Based on previous work on Linking GSIM and GSBPM, Inkyung mentioned 3 types of output (core output, process metric, process execution log type). She suggested it could also include execution data, about change logs for software.

Edgardo was puzzled by the meaning of the word “implementation” of the statistical business process in the bullet point description. Gabriel wasn’t sure if it related to quality assurance/management. He suggested Process Data Management could be split in two parts (quality parts and data management parts). Edgardo could see the quality management aspect, but thought the data part was more about raising alarms if the process run has a problem.

Edgardo suggested it might include measuring how long the data collection took (perhaps at the level of individual interviewers/enumerators), and compare with the next round, as patterns could reveal a process problem.
InKyung confirmed that GSBPM Quality Indicators include length of time needed to run the collections, but not for small-scale steps. Therefore a quality indicator can be obtained from this data, but that data is not quality data itself.

Juan suggested asking other experts to provide a description. If they don’t recognize it, he would recommend removing this bullet from the list of OPs.

Provider Management

InKyung said she wasn’t sure if Provider Management should be part of GSBPM, since much of the text in the bullet point is the same as GAMSO’s “Manage Data Suppliers” activity (which also mentions cross-process burden management, contact information, and registers.) She said there are too few touch points for Provider Management to be overarching for the entire production process. Gabriel suggested avoiding overlap between GSBPM and GAMSO.

Edgardo suggested this was about sharing/knowing/documenting who are the contact points for external data sources. He highlighted the parts about “profiling and managing contact information” and “cross-process burden management”.
Juan mentioned business registers, which can be considered external register based data, and said these contain contact details that can be used for obtaining data from businesses.
InKyung asked whether business registers deserve special treatment, as there are other sources of data (e.g. admin data) for which contact information may be needed.

Regarding the similarity between the bullet point text description and the description of GAMSO’s “Manage Data Suppliers” activity, Edgardo suggested the GAMSO part might be more about managing a MoU (compliance with it, etc.), but from the GSBPM side its more about having a technical contact to ask questions to about the data (e.g. about its detailed characteristics, like meaning of new variables, missing data, anomalies, etc.).

Gabriel suggested that anything not strictly related to managing production should be in GAMSO, and that should be the dividing line between GSBPM and GAMSO, for ease of understanding of the readers. He suggested we could just link from GSBPM to GAMSO text.

In the next call, we will dig up any remaining unresolved issues.