5.1 Data Workflows & Typology
Understanding how programme data moves — from its point of collection to its final use or disposal — is essential for effective and responsible Information Management. Mapping data workflows helps organizations visualize who collects what, when, using which tools, and for what purpose. It also clarifies ownership, responsibilities, and identifies inefficiencies, overlaps, and risks across the data lifecycle.
This chapter introduces a structured approach to mapping data workflows and typologies, using field-tested tools and templates to support IMOs in leading or facilitating this process.
5.1.1 Why Map Programme Data Workflows?
Mapping your data management cycle brings several benefits:
Visual clarity on each stage of the data lifecycle: collection, cleaning, storage, use, sharing, and disposal.
Improved efficiency, by identifying redundant or unused data.
Defined roles and responsibilities at each stage, enabling better coordination and accountability.
Informed tool selection: choosing the right tools for each step becomes easier when the full picture is visible.
Enhanced data protection: understanding data flows is a prerequisite for secure data handling.
Programme data mapping also serves as a practical foundation for building SOPs and establishing governance routines.
5.1.2 What to Map: Key Dimensions
To comprehensively map a programme data workflow, the following elements should be captured at each stage of the cycle:
Type of Data
What is being collected?
Define the nature of the data: quantitative, qualitative, categorical, sensitive, geospatial, etc.
Data Collection Tool/Form
What is the actual format used by field staff to collect the data?
This refers to the frontline tool used by staff.
Examples: Kobo form, Excel spreadsheet, paper form, SurveyCTO template, SMS-based checklist.
Platform or System
What digital system hosts, processes, or manages the data?
This refers to the underlying software or ecosystem where data is stored, visualized, or analyzed.
Examples: ActivityInfo, Power BI, ONA, DHIS2, SharePoint.
Person Responsible
Who manages or oversees this step?
Include names or roles.
Examples: IM Officer, Project Manager, M&E Officer, Database Manager.
Frequency
How often is data collected or updated?
Daily, weekly, monthly, quarterly, ad hoc, real-time.
Sharing Channel
How is the data transmitted?
Email, online sync, secure file share, USB handover, internal server, etc.
Storage & Disposal
Where is the data stored? When and how is it deleted or archived?
Physical or digital location, access controls, and deletion/archiving process (e.g., encrypted drive, cloud archive, retention policy).
This breakdown helps ensure that no step in the lifecycle is overlooked and that risks are addressed from the outset.
Example of a Programme Data Management Mapping Template
A visual of a practical tool for mapping data flows across a programme’s lifecycle is shown below. This visual approach can help teams document which tools are used at each stage (collection, management, sharing, storage, disposal), identify overlaps or gaps, and promote harmonization across programmes.
📌 This diagram is a visual adaptation of a tool developed by Première Urgence Internationale, originally created by Julio Casas (MEAL Coordinator, Yemen Mission). It serves as an illustrative reference to help you conceptualize your data mapping process. To use the full editable template, please refer to the accompanying PowerPoint file in 5.1 Data Workflows & Typology
5.1.3 The Data Typology: What Kind of Data Are You Managing?
In addition to mapping processes, IMOs should categorize the types of programme data being handled. A simple typology can include:
Operational data: Related to project implementation (e.g., number of participants, distributions, sessions conducted).
Monitoring data: Regular indicators used for performance tracking.
Evaluation data: In-depth data for learning and accountability (e.g., outcome surveys, FGDs).
Protection-sensitive or personal data: Names, contacts, vulnerabilities — requires high-level safeguards.
Understanding what kind of data you are managing will inform decisions about tool selection, storage, anonymization, and access controls.
5.1.4 PUI Tool to Support Workflow Mapping
Première Urgence Internationale (PUI) developed a methodology and template for programme data mapping, which can be adapted to your context. It includes:
An Excel-based tool for gathering data about each collection point, tool, and person involved.
A PowerPoint template to visually represent the workflow in a standardized way.
Guidance on analysis, including how to identify duplications, role gaps, underused data, and workflow bottlenecks.
These tools are simple, visual, and can be adapted to specific sectors (e.g., Health, Protection) or cross-cutting themes (e.g., MEAL, Accountability).
5.1.5 What Does It Mean to Have a Repository — and What Are Its Benefits?
A data repository is a centralized system or location where structured data is securely stored, organized, and maintained for ongoing access and use. It is not just a digital folder, but a managed environment where data is versioned, cleaned, and linked to its metadata (e.g., source, time, method of collection).
Benefits of a repository include:
Efficiency: Reduces duplication by making data accessible across teams
Continuity: Ensures that data outlives staff turnover or emergencies
Accountability: Allows for traceability and transparency of programme data
Security: Supports access control and safe storage of sensitive information
Interoperability: Allows tools and systems to interact via shared structures (e.g., APIs, flat files)
Repositories can take many forms — from structured folder systems with naming conventions to cloud-based platforms like SharePoint, Kobo, DHIS2, or custom SQL databases. What matters is consistency, governance, and ease of use.
5.1.6 Guidance on Creating Libraries of Terminology
Terminology libraries (sometimes called indicator banks or taxonomies) are essential for ensuring that data is collected, reported, and interpreted consistently across projects and stakeholders.
Key components of a good terminology library:
Programme Delivery Data Standards: Standardized definitions for core programme processes — such as needs screening, eligibility scoring, registration, service delivery tracking, and referrals. This includes reviewing and harmonizing all forms and templates used across services (e.g., education, protection, shelter), to ensure consistency and interoperability across the organization’s global operations.
Population categories: Agreed terms for age groups, vulnerability profiles, geographic labels, etc.
Data formats: Defined response types (e.g., text, number, single choice) that align with tool design
Version control: Updates tracked over time with documented changes
Indicator definitions: Clear formulas, disaggregation rules, and source guidance
Tips for development:
Start with existing existing programme forms and templates; review internal tools used for registration, service tracking, case management, or referrals to identify core variables and data points in current use.
Align with sector standards (e.g., Sphere, IASC, HXL tags) where relevant to ensure interoperability.
Collaborate with programme and MEAL teams to ensure terms are practical, clearly defined, and usable in field contexts.
Maintain the library as a shared, living document — not a static file — with version control and update logs.
See 5.2 Data Standardization & Data Harmonization for more on standardization practices and tools.
5.1.7 Mapping Data Flows in an Area Office (AO)
Area Offices often serve as the operational core of programme delivery — and data management processes at AO level are where most friction and fragmentation occur. Mapping workflows at this level helps identify:
Which tools are actually used in the field for delivering services, including registration, intake, referrals, case management, or activity tracking, and how consistently they are applied across projects.
Who is responsible for what in the lifecycle
Gaps or inconsistencies between expected and actual practices
Points of data loss or delay
This process should include:
Holding cross-functional workshops (IM, programme, MEAL, protection)
Using the workflow mapping template to chart real practices, not just SOPs
Including qualitative feedback on pain points or workarounds
AO-level mapping is often the most revealing and actionable — it helps align HQ or CO guidance with field realities and enables targeted support where it’s most needed.
REFERENCES & FURTHER READINGS
Last updated