Applying DAMA-DMBOK to Humanitarian Data Initiatives

Anchoring the Argument in the DAMA Data Management Principles

The DAMA-DMBOK rests on a set of data management principles that fall under four themes: data is valuable; data management requirements are business requirements; data management depends on diverse skills; and data management is lifecycle management. These are the test against which any data management arrangement, including the lightweight model proposed here, should be evaluated.

For humanitarian organizations, the four themes translate directly into the problems this article addresses:

• Data is valuable. The data produced by a country-office program officer, a regional analyst, or an HQ specialist is an organizational asset. Treating it as a personal artefact that disappears when its originator rotates is inconsistent with this principle.
• Data management requirements are business requirements. Managing data quality, planning the architecture and metadata that hold data together, and ensuring that technology serves data needs are business questions for sector leads and operational managers, not purely technical questions for an IM unit.
• Data management depends on diverse skills. DMBOK2 is explicit that data management is cross-functional and requires an enterprise perspective. A humanitarian organization with country offices, regional offices, HQ functions, sector leads, programme heads, and results managers fits this principle exactly.
• Data management is lifecycle management. Data has a lifecycle, and the risks associated with it, including the risk of losing data when initiatives are not formally managed across staff transitions, must be managed as part of that lifecycle.

The argument is straightforward: the model proposed here is what these four DMBOK principles look like applied to a humanitarian organization operating across country, regional, and HQ levels under high staff mobility and constrained resources.

Why This Matters: Continuity in a Mobile Workforce

People in humanitarian work move, between emergencies, country offices, regional hubs, and HQ, and often. The mobility brings real benefits, but it also creates a continuity problem the sector has long recognized, and one the DMBOK principles speak to directly.

The ODI Humanitarian Practice Network’s Network Paper 55 (Loquercio, Hammersley & Emmens, Understanding and Addressing Staff Turnover in Humanitarian Agencies, 2006) noted that unplanned staff turnover affects “learning and efficiency” and “the capacity of agencies to respond to new emergencies, or even sometimes just to continue existing programmes,” with institutional memory loss as one of the most persistent consequences. ALNAP’s 2022 paper Learning to Change observes that humanitarian organisations often struggle to convert individual experience into institutional knowledge. The IASC Operational Guidance on Data Responsibility in Humanitarian Action (OCHA Centre for Humanitarian Data, 2021) points to the constructive response: institutional structures, defined roles, and documented processes are what allow data work to be both responsible and durable.

If a data initiative is recognized, documented, and supported, it becomes something the organization carries forward, not something that depends on whether one person is still in post.

The Structural Opportunity: Why a Hybrid Operating Model Fits

Most humanitarian organizations work across three levels. Country offices run the operational programs. Regional offices coordinate across the country operations in their region. HQ sets strategy, policy, and global standards.

An operating model describes how authority and responsibility for data governance are distributed across an organization: who sets the rules, who applies them, and how the central and local levels relate. The DAMA-DMBOK describes five such models: Decentralized, Network, Centralized, Hybrid, and Federated.

For humanitarian organizations, the hybrid model maps most directly onto how things actually work. A hybrid model combines a central core with distributed local groups: a centralized center of excellence (a small central team that sets standards and provides support) works alongside decentralized business unit groups (here, the regional and country teams), connected through an executive steering committee and a set of tactical working groups. It keeps standards consistent at the center while leaving day-to-day data work in the hands of the teams closest to operations.

The match is straightforward. HQ is the natural home for data strategy, data policy, global data standards, data ethics, and data protection requirements (linked to the ICRC Handbook on Data Protection in Humanitarian Action, 2nd Edition, 2020). Regional offices adapt those standards to local context and coordinate across country operations. The field is where data is produced and where most innovation begins. The hybrid model keeps HQ’s role in standards while leaving the field its operational agility.

The DAMA-DMBOK favours incremental rollout over a single large programme, which suits constrained settings well. Most organizations already have a SharePoint, Confluence, or Teams environment that can serve as the central online home for a governance charter, role descriptions, and standards. A minimum data initiative registry (one accessible spreadsheet listing name, originator, owner, purpose, status, and documentation link) is the lightest useful form of business metadata. A short handover protocol added to existing HR offboarding, and a 15-minute data governance item on an existing senior management agenda, provides the operational backbone at no additional cost.

A Lighter Set of Roles That Can Be Adopted Without Restructuring

Data governance for operational humanitarian data is cross-functional. It does not belong to the Information Management unit, the M&E unit, or any single function. Most operational data initiatives originate inside sector or cluster teams, programmes, or M&E and results functions. The role names below are neutral and can be assigned to existing staff regardless of unit.

The principle: subsidiarity. Subsidiarity is the principle that decisions should be taken at the lowest level capable of handling them, and pushed up only when they genuinely need a higher level. Applied to data governance, a structure for 100+ country operations cannot work if every level tries to see everything below it. Each level handles what is its own responsibility, and only what cannot be resolved there is escalated upward. Country offices decide on country-level initiatives; regional offices see aggregates from countries plus their own initiatives; HQ sees aggregates from regions plus its own HQ-level initiatives plus exceptions.

Initiatives originate at all three levels and across all operational functions. A sector or cluster lead building an indicator framework. A head of program consolidating cross-sector program data. A results manager designing a monitoring system. An M&E officer developing an evaluation approach. An information management officer building a data quality tool. A needs assessment lead building a multi-sector methodology. Each is a legitimate initiative with its own Initiator.

The Initiator (DMBOK2 Business Data Steward). Whoever proposed, designed, or piloted the initiative. They register it under their own name, maintain a one-page document explaining what it does and how it was built, complete a structured handover before any rotation, and stay attributed as the originator for the lifetime of the initiative.

The Country Data Coordinator (DMBOK2 Coordinating Data Steward). A named focal point inside the country office, working across sectors and units. Can be filled by the country IM officer, the country M&E lead, a country data adviser, or the head of programmes acting in this capacity. Maintains the country register, supports Initiators from any sector, resolves country-level coordination locally, and surfaces to the regional office only those initiatives meeting defined criteria.

The Regional Data Coordinator (DMBOK2 Enterprise Data Steward). Works from what country offices roll up plus regional-level initiatives. Does not inspect country-level detail. Can be filled by the regional IM adviser, regional M&E adviser, or a dedicated regional data adviser. Coordinates between country offices when an initiative is relevant to others, and surfaces to HQ only those meeting defined criteria.

The Global Data Lead (DMBOK2 Chief Data Steward, or acting Chief Data Officer). The most senior data role at HQ for operational humanitarian data. Does not see every initiative in every country. Maintains the global register of HQ-level and adopted organizational initiatives, identifies integration opportunities, chairs the Data Governance Council.

The Data Owner (DMBOK2 Data Owner). The senior leaders at HQ who own the operational data of their sector or function: sector and cluster leads for sectoral data, the head of program for cross-sector programme data, the head of results for results data, the head of M&E for evaluation data, the head of needs assessment for needs assessment data. Not data specialists; the people whose data it is. They set the rules for their domain across the organization, including data protection requirements, and provide the authoritative reference when substantive questions are escalated.

The Data Governance Council (DMBOK2 Data Governance Council). Brings together the global data lead (who chairs), the data owners, and on a rotating basis a regional data coordinator. Sets the rules, decides on formal adoption of initiatives for organizational scaling, resolves substantive escalations, and reviews exception reports. Decisions on initiatives that belong at country or regional level remain at those levels.

The data and coordination functions facilitate; the sector and operational leaders decide.

Before Anything Else: Should This Initiative Exist?

The question of whether to start matters more than how to manage what starts. Two checks apply before an initiative is registered.

Check 1: Is this already covered by a corporate platform? The most common waste happens when staff at country or regional level build something the organization already provides as a corporate platform: a beneficiary management system, a needs assessment tool, a monitoring platform, an analytics environment. The local solution sits outside the data architecture, generates data nobody else can use or trust, and creates a continuity risk that does not exist in the corporate platform. The country and regional data coordinators check this before registration. If the corporate platform is too slow, rigid, or missing a feature, the response is to engage its global owner, not to build a parallel solution. This reflects a core idea in the DAMA-DMBOK: data architecture is foundational to data management, and one of its purposes is to prevent the unmanaged proliferation of data assets that an organization cannot sustain.

Check 2: Does the initiative cover a real gap? Where the corporate platform genuinely does not cover the need, the initiative addresses a real gap and deserves support. A real gap usually looks like one of the following: the operational context has a specific characteristic no corporate platform was designed for; the data is needed at a frequency or granularity the platform cannot deliver; the decision is local enough that the platform’s scope does not reach it; or the platform exists but is so outdated or unsupported that it cannot be relied upon. When one of these is true, the role of the structure here is to protect the initiative (register, document, support), not to obstruct it.

Designing for Sustainability from the Start

Once an initiative passes the two checks, three design considerations apply.

Storage and continuity. A data initiative whose files sit on the originator’s laptop, in a personal cloud account, or in an undocumented folder will eventually become inaccessible. Storage and continuity decisions are made at registration. The initiator confirms the storage location is sanctioned, access is governed by the rules of the relevant data owner, backup follows organizational standards, and the end-of-life plan is documented.

Architectural fit. In the DAMA-DMBOK view, data architecture is what connects business strategy to technical execution, so a new initiative should be designed to fit the wider landscape rather than in isolation. Three questions are answered before registration: does the initiative use the organization’s standard identifiers (beneficiaries, projects, locations, partners, indicators), do the data structures align with existing models for the sector, and are the data flows in and out sanctioned by the relevant platform owners.

Stewardship anchors: business glossary and data catalog. In data management practice, the business glossary is the authoritative record of what an organization’s business concepts actually mean. Without it, two teams using “beneficiary” can mean two different things. The data catalog is the inventory of data assets. At early maturity, the glossary starts small, covering the terms most likely to be misread across operations: beneficiary, household, partner, indicator, response, project, location, displacement status, with definitions agreed by the relevant data owners. The catalog can begin as the same registry used for initiatives.

HQ as Enabler, Not Gatekeeper

The model is reciprocal. If country and regional offices register, document, and surface initiatives upward, HQ provides what makes that possible. A field office cannot comply with standards that have not been published, integrate with a catalog that does not exist, or align with a glossary that has never been written.

In a hybrid model, the central data function is a center of excellence whose role is to provide training, design best practices, data source guidance, and active support to business units. The DAMA-DMBOK treats the spread and adoption of new practice, the diffusion of innovation, as a core organizational-change concern rather than an afterthought.

Five HQ obligations are prerequisites for the model to work:

• A published business glossary covering cross-cutting humanitarian concepts, confirmed by the relevant data owners.
• A maintained data catalog of corporate data assets with owner, scope, status, and access conditions.
• A documented process for assessing and integrating field initiatives, specifying who reviews, what evidence is required, what the decision criteria are, and what happens at each outcome.
• A documented process for integrating important changes to existing platforms. Without it, the field choice is between waiting indefinitely and building a parallel solution.
• Active support, not passive availability: training, design best practices, technical guidance, and direct engagement with the originators of promising work.

When these obligations are not met, the consequences are predictable: field offices invent their own definitions and storage; parallel solutions appear next to corporate platforms; valuable innovations are absorbed without credit; and governance becomes visible process without real outcomes.

Innovation Cannot Be a Parallel Track

An innovation lab, an innovation fund, a one-off challenge, or a discrete pilot can all be valuable starting points. The difficulty is rarely the prototype itself. It is the absence of a space to move a promising prototype out of the lab and into something large enough to serve the wider organization. Without a defined route from prototype to project, and from project to scale, good ideas stay confined to where they began.

The DAMA-DMBOK treats the diffusion of innovation as part of organizational change management: how a new practice spreads through an organization, or fails to. Three structural patterns stop that diffusion.

Innovation in a separate organizational unit. When innovation is concentrated in a dedicated unit outside the operational chain, its outputs remain disconnected from the country offices, regional offices, sector leads, and Data Owners who would have to adopt them.

Project-based innovation without an integration path. When work is structured as a project with a closure milestone but no defined path for what happens after, the project ends and the innovation ends with it. Change tends to last only when an operational owner is named from the start, not assigned at the end.

Single-operation success with no scaling mechanism. A country office develops a successful tool, but there is no documented process for adoption elsewhere. The innovation stays where it was built and the value never compounds.

A working integration path has four conditions:

• A defined lifecycle from prototype to organisational asset, moving through concept, pilot, validated, and adopted stages with documented criteria for advancing.
• An operational owner identified from the start, typically the relevant sector lead, head of program, head of results, head of M&E, or head of needs assessment.
• A change management process that scales the change, not just the artefact: training, support, alignment with corporate standards, integration with corporate platforms, and migration of existing local data.
• Integration with the corporate environment, not parallel to it, so the corporate platform absorbs the innovation rather than being replaced by it.

The same discipline applies when an initiative originates at HQ. A new HQ initiative should begin by bringing together the people who have already done similar work in the field. The field has usually tried, tested, and learned from earlier attempts at the same problem, and that experience is the best protection against repeating mistakes others have already solved. Convening field practitioners at the design stage turns scattered individual knowledge into joint intelligence, and it signals that field contributions are valued rather than bypassed. HQ initiatives should also follow the same clear, documented process the rest of this article describes: registered, classified, and visible to the regions and countries they will affect, so that no part of the organization discovers a global initiative only after it has been built.

Classification and Key Questions

A new initiative is easier to assess when placed on a shared classification.

Relationship to existing work: New (addresses a problem no registered initiative covers); Variant (similar problem, meaningfully different approach, scope, or context); Extension (builds on a registered initiative, adding capability); Convergent (overlaps substantially; the path forward is integration, not termination).

Stage of development: Concept (not yet piloted); Pilot (one location or user group, early evidence); Validated (demonstrated value across more than one location); Adopted (formally integrated into organisational systems).

Variant and extension classifications are signals to plan integration, not reasons to stop work. A convergent classification brings the initiators together rather than moving the work away from any of them. The aim is a structured conversation that joins their efforts into a single stronger initiative, with every contributor named and credited. An initiative that originated in the field does not lose its authorship when it is scaled, and it is never quietly relabelled as an HQ initiative. The sponsor and the global data lead facilitate this conversation; they do not appropriate its outcome.

Key questions for sustaining a data initiative, applied at registration, when the Initiator moves, and when the initiative is proposed for adoption:

• Authorship and ownership: Who initiated this work? Who is the current operational owner? Which data owner has authority over the data domain?
• Pre-checks: Is this work already covered by an existing corporate platform? If no, what gap does it cover?
• Design: Is the storage location sanctioned and the end-of-life plan documented? Does the initiative use the organization’s standard identifiers and structures? Are the data flows sanctioned by the relevant platform owners?
• Relationship to existing work: Has the initiative been classified? If variant or extension, what is the integration pathway? If convergent, what is the plan to bring the work together?
• Continuity: Is there a one-page document covering what the initiative does, how it was built, and where its files live? If the Initiator moved tomorrow, who would carry on, and do they have access?
• Adoption: Has an operational owner been identified for the post-prototype stage? Has the council reviewed it? If adopted, has the initiator’s attribution been preserved?

The DMBOK Data Management Maturity Model

Why include a maturity model at all? Because it answers the question every reader will eventually ask: where is my organization now, and what is a realistic next step? The model gives that question a shared vocabulary. It lets an organization locate itself honestly, set a reachable target rather than an aspirational one, and see that the gap between depending on a few capable individuals and having durable institutional practice is crossed in stages, not in a single leap. The lightweight model in this article is designed to move an organization one or two of those stages, not all of them at once.

The DAMA-DMBOK uses a six-level maturity model, summarised below. The descriptions of Levels 1 and 3 are quoted directly because the argument of this article turns on the move between them; the others are paraphrased.

The approach in this article aims at a realistic next step for many humanitarian organizations: moving from Level 1 toward Level 2 and Level 3. The CMMI Data Management Maturity (DMM) Model points in the same direction.

Conclusion

Good data initiatives in humanitarian work should be recognized as organizational assets from the moment they begin. This is the first DMBOK data management principle, applied. The hybrid operating model offers a structure that fits the way humanitarian organizations are built: strategy and standards at HQ, coordination at the regional level, operational accountability in the field. The cross-functional design reflects the principle that data management depends on diverse skills and requires an enterprise perspective. The integration pathway reflects the principle that data management is lifecycle management.

Most of this can be put in place without restructuring and without new staff: a small set of roles, a pre-registration check on duplication and gap, a design discipline anchored in storage, architecture, and stewardship, a reciprocal set of HQ obligations, an integration path that brings innovation inside the normal lifecycle, a classification scheme, and a sustainability checklist. Together they form a chain that supports an initiative from origination to organisational adoption.

The point is not a perfect governance system. The point is a steady move from Level 1 toward Level 2 and Level 3 maturity, where good ideas are recognized, supported, and carried forward by the organization rather than by chance. When data initiatives are looked after this way, the people who build them are looked after too. The organization gains something durable, and the people it serves benefit from work that does not have to be reinvented every time someone moves.