Programme Management Systems
A programme management information system (PMIS) coordinates planning, implementation tracking, resource allocation, and reporting for humanitarian and development programmes. These systems provide the operational backbone connecting strategic planning to field delivery, capturing what activities are planned, what resources are allocated, what progress has been made, and what outputs have been achieved. IT staff responsible for programme technology must understand how PMIS architecture supports multi-year, multi-country operations while integrating with finance systems for budget tracking and with monitoring and evaluation platforms for results measurement.
- Programme
- A collection of related projects and activities managed in a coordinated way to achieve outcomes that individual projects cannot deliver independently. Programmes span multiple years and adapt based on learning.
- Project
- A time-bound initiative with defined deliverables, budget, and end date. Projects exist within programmes and typically align with funding agreements.
- Activity
- A discrete unit of work within a project, assigned to specific staff or partners, with measurable completion criteria.
- Work breakdown structure
- The hierarchical decomposition of programme scope into progressively smaller components: programme to project to output to activity to task.
- Results framework
- The logical hierarchy connecting activities to outputs to outcomes to impact, defining the programme’s theory of change in measurable terms.
- Indicator
- A quantifiable measure that tracks progress toward planned results. Indicators exist at output, outcome, and impact levels.
Programme management architecture
Programme management systems operate at the intersection of planning, execution, and accountability. The core function is maintaining alignment between what an organisation intends to do, what resources it has committed, and what it has actually delivered. This alignment requires data structures that model organisational hierarchies, funding relationships, and implementation timelines simultaneously.
The fundamental architectural challenge stems from the multiple hierarchies that intersect within any programme. Geographic hierarchies span headquarters to regional offices to country offices to field sites. Organisational hierarchies span the lead organisation through implementing partners to local community structures. Funding hierarchies span institutional donors through prime recipients to sub-grantees. Thematic hierarchies span sectors and sub-sectors. A single activity exists at the intersection of all these hierarchies and must be reportable along each dimension.
+-------------------------------------------------------------------+| PROGRAMME MANAGEMENT SYSTEM |+-------------------------------------------------------------------+| || +---------------------------+ +-----------------------------+ || | PLANNING MODULE | | EXECUTION MODULE | || | | | | || | +-------------------+ | | +---------------------+ | || | | Results Framework | | | | Activity Tracking | | || | | - Outcomes | | | | - Task status | | || | | - Outputs | | | | - Assignments | | || | | - Indicators | | | | - Dependencies | | || | +-------------------+ | | +---------------------+ | || | | | | || | +-------------------+ | | +---------------------+ | || | | Work Breakdown | | | | Resource Tracking | | || | | - Projects | | | | - Time allocation | | || | | - Activities | | | | - Budget burn | | || | | - Tasks | | | | - Procurement | | || | +-------------------+ | | +---------------------+ | || | | | | || | +-------------------+ | | +---------------------+ | || | | Budget Planning | | | | Issue Management | | || | | - Cost estimates | | | | - Risks | | || | | - Funding sources | | | | - Blockers | | || | | - Phasing | | | | - Decisions | | || | +-------------------+ | | +---------------------+ | || +---------------------------+ +-----------------------------+ || || +---------------------------+ +-----------------------------+ || | REPORTING MODULE | | INTEGRATION LAYER | || | | | | || | +-------------------+ | | +---------------------+ | || | | Donor Reports | | | | Finance System | | || | | - Narrative | | | | - Actuals sync | | || | | - Financial | | | | - Budget codes | | || | | - Indicators | | | +---------------------+ | || | +-------------------+ | | | || | | | +---------------------+ | || | +-------------------+ | | | M&E Platform | | || | | Internal Reports | | | | - Indicator values | | || | | - Dashboards | | | | - Evidence links | | || | | - Scorecards | | | +---------------------+ | || | | - Alerts | | | | || | +-------------------+ | | +---------------------+ | || | | | | HR System | | || +---------------------------+ | | - Staff allocation | | || | +---------------------+ | || +-----------------------------+ |+-------------------------------------------------------------------+The planning module maintains the intended state: what the programme aims to achieve, what activities will produce those achievements, and what resources are required. The execution module captures actual state: what tasks have been completed, what resources consumed, what issues encountered. The reporting module synthesises planned versus actual into formats required by donors, management, and governance bodies. The integration layer synchronises with authoritative sources for financial actuals, indicator values, and staff assignments.
Data model foundations
The data model underlying a PMIS must capture both the hierarchical structure of programmes and the dimensional analysis requirements of reporting. At the centre sits the activity record, which carries attributes linking it to every relevant hierarchy.
A single activity might be defined as: “Conduct emergency shelter distribution in Maiduguri” belonging to Project NG-2024-001 (Nigeria Emergency Response), funded by ECHO under Grant Agreement ECHO/NGA/BUD/2024/91000, implemented by Partner Organisation Mercy Corps, contributing to Output 1.2 (Emergency shelter provided to conflict-affected households), measured by Indicator 1.2.1 (Number of households receiving emergency shelter kits), scheduled for Q2 2024, budgeted at €45,000 under budget line 3.1 (Relief Items), assigned to Field Manager J. Adamu.
The data model must support queries that aggregate this activity along any dimension: total budget by donor, total activities by country, progress by output, expenditure by partner, and combinations thereof. This dimensional analysis requirement drives the entity-relationship structure.
+-------------+ +-------------+ +-------------+| DONOR | | GRANT | | PROJECT |+-------------+ +-------------+ +-------------+| donor_id |<------| donor_id |<------| grant_id || name | | grant_id | | project_id || requirements| | amount | | name || portal_url | | start_date | | start_date |+-------------+ | end_date | | end_date | | currency | | budget | +-------------+ | country_id | | +-------------+ | | v v +-------------+ +-------------+ | BUDGET_LINE | | ACTIVITY | +-------------+ +-------------+ | line_id |<------| activity_id | | grant_id | | project_id | | category | | output_id | | amount | | partner_id | +-------------+ | budget_line | | | location_id | | | status | v | planned_qty | +-------------+ | actual_qty | | EXPENDITURE | +-------------+ +-------------+ | | exp_id | v | line_id | +-------------+ | activity_id |<------| INDICATOR | | amount | | VALUE | | date | +-------------+ | voucher_ref | | value_id | +-------------+ | activity_id | | indicator_id| | period | | target | | actual | +-------------+The relationship between grants and projects is many-to-many in complex programmes. A single project draws funding from multiple grants when donors contribute to pooled programmes. A single grant funds multiple projects when institutional donors provide umbrella agreements covering several countries. The budget line entity mediates this relationship, allocating portions of grant funding to specific expenditure categories that map to project activities.
Scope dimensions
Programme management systems serve three distinct management scopes that require different functionality and different user interfaces.
Project management addresses the delivery of individual funded initiatives. The scope is a single grant or contract with defined deliverables, timeline, and budget. Users are project managers responsible for on-time, on-budget delivery. The system supports detailed task management, Gantt chart visualisation, resource assignment, and milestone tracking. Reporting serves the specific donor for that grant.
Programme management addresses coordination across related projects toward shared outcomes. The scope spans multiple grants, possibly multiple donors, unified by a common theory of change. Users are programme managers responsible for strategic coherence and adaptive management. The system supports cross-project dependencies, consolidated indicator tracking, portfolio-level risk management, and outcome-level reporting. The programme view reveals whether individual project successes aggregate to meaningful impact.
Portfolio management addresses resource allocation across all organisational programmes. The scope is the entire programme portfolio, used for strategic decision-making about where to invest. Users are senior leadership and board members. The system supports portfolio visualisation, comparative performance analysis, strategic alignment scoring, and resource optimisation. The portfolio view informs decisions about which programmes to expand, maintain, or phase out.
+-------------------------------------------------------------------+| PORTFOLIO LEVEL || Strategic: Where should we invest? || Users: Executive leadership, board |+-------------------------------------------------------------------+ | | | | v v v v+---------------+ +---------------+ +---------------+ +---------------+| PROGRAMME A | | PROGRAMME B | | PROGRAMME C | | PROGRAMME D || Health | | Education | | Livelihoods | | Protection || Outcome focus | | Outcome focus | | Outcome focus | | Outcome focus |+---------------+ +---------------+ +---------------+ +---------------+ | | | | | | | | | v v v v v v v v v+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+|Proj | |Proj | |Proj | |Proj | |Proj | |Proj | |Proj | |Proj ||A.1 | |A.2 | |B.1 | |B.2 | |C.1 | |C.2 | |D.1 | |D.2 ||ECHO | |USAID| |FCDO | |SDC | |EU | |WFP | |UNHCR| |ECHO |+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+Many organisations conflate these scopes, using project management tools for programme oversight or attempting portfolio analysis from spreadsheet aggregation. Each scope requires purpose-built functionality. A project management tool optimised for task-level Gantt charts provides poor support for cross-project outcome analysis. A portfolio dashboard designed for executive summaries obscures the implementation detail project managers need.
Platform landscape
Programme management systems range from general-purpose project management tools adapted for development contexts to purpose-built platforms designed specifically for humanitarian and development programme management.
Open source platforms
OpenProject provides comprehensive project management with work breakdown structures, Gantt charts, time tracking, and budget management. The system supports multi-project views and customisable workflows. Deployment requires a server with 4GB RAM minimum and PostgreSQL database. The community edition covers core functionality; the enterprise edition adds advanced reporting and LDAP integration. Organisations self-hosting OpenProject gain full data control and can extend functionality through plugins. The European origin and self-hosting capability address data sovereignty requirements.
Odoo Project integrates project management within the broader Odoo ERP ecosystem. Projects link directly to sales orders, purchase orders, and financial accounting. The tight ERP integration benefits organisations seeking unified business systems. The modular architecture allows selective deployment of only needed components. Odoo’s open core model means some advanced features require the enterprise edition. Self-hosting requires Linux administration skills and PostgreSQL expertise.
ERPNext Projects provides project management as part of the ERPNext framework. Task management, timesheet tracking, and budget integration connect to accounting and HR modules. The system particularly suits organisations already using ERPNext for finance. Indian origin and active development community. Self-hosting on Frappe Cloud or own infrastructure.
Taiga offers agile project management with Scrum and Kanban support. While designed for software development, the customisable workflow engine adapts to programme management. The clean interface and strong API support integration with other systems. Lighter weight than full ERP-integrated options, suitable for organisations needing focused project tracking without ERP complexity.
Commercial platforms with nonprofit programmes
Microsoft Project integrates with the Microsoft 365 ecosystem through Project for the Web (cloud-native) or Project Online (SharePoint-based). Nonprofit pricing through Microsoft 365 Nonprofit programmes reduces licensing costs substantially. Deep integration with Teams, SharePoint, and Power BI supports organisations standardised on Microsoft. Cloud deployment means data resides in Microsoft Azure, subject to US jurisdiction and CLOUD Act. Project for the Web provides simplified task management; Project Online offers full enterprise project management with resource planning and portfolio analysis.
Asana offers work management with project views, timelines, and portfolio tracking. The nonprofit programme provides discounted pricing for qualifying organisations. Strong API enables integration with other systems. Data residency in US datacenters with EU and Australia options for enterprise plans. The shift from pure project management to broader work management suits organisations wanting task coordination beyond formal projects.
Monday.com provides flexible work operating system adaptable to programme management. Customisable boards and dashboards. Nonprofit pricing available. Strong visualisation capabilities and automation features. Cloud-only deployment with data primarily in US and EU regions.
Smartsheet combines spreadsheet familiarity with project management capabilities. Strong adoption in the development sector due to spreadsheet-like interface that eases transition from Excel-based tracking. Nonprofit pricing through TechSoup. Forms, dashboards, and automation capabilities. Cloud deployment with enterprise plans offering data residency choices.
Sector-specific platforms
DevResults targets international development specifically, with built-in support for indicator tracking, geographic disaggregation, and USAID reporting requirements. Activity monitoring plans connect activities to indicators to results frameworks. The sector focus means reporting templates align with common donor requirements. Pricing based on organisation size. Cloud deployment.
TolaData provides open-source programme management designed for humanitarian and development contexts. Activity tracking, indicator management, and evidence documentation. Can be self-hosted or used as managed service. The open-source nature allows customisation and addresses data sovereignty concerns. Developed from USAID-funded work, with governance now through TolaData GmbH.
ActivityInfo focuses on humanitarian information management with strong support for cluster coordination and multi-organisation data collection. While primarily a data collection and indicator platform, the programme management features support activity planning and tracking. Established use in humanitarian coordination contexts. Cloud deployment with organisation-controlled databases.
Selection considerations
The choice among platforms depends on existing technology investments, integration requirements, data sovereignty constraints, and organisational capacity.
| Factor | Weight for selection |
|---|---|
| Existing ERP/finance system | High: integration with financial actuals determines budget tracking accuracy |
| Donor reporting requirements | High: sector-specific platforms pre-build required report formats |
| Geographic distribution | Medium: offline capability matters for field-heavy operations |
| Data sovereignty requirements | Medium: self-hosting options required for sensitive programmes |
| IT capacity | Medium: self-hosted platforms require ongoing maintenance |
| Multi-language requirement | Medium: interface localisation and content translation support |
Organisations with established Microsoft 365 deployments find Project integration natural but should evaluate whether Microsoft’s project management capabilities meet programme-level requirements or remain focused on project task management. Organisations prioritising data sovereignty should evaluate self-hosted options including OpenProject and TolaData against the maintenance burden. Organisations with USAID funding should evaluate DevResults and ActivityInfo against the specific reporting requirements in their awards.
Integration patterns
Programme management systems must integrate with finance systems to reconcile planned budgets against actual expenditure, with M&E platforms to connect activities to measured results, and with grants management systems to maintain funding relationship accuracy.
Finance integration
The finance integration serves two purposes: pushing budget data from programme planning to create financial structures, and pulling expenditure data from financial accounting to compare against budgets.
Budget data flows from PMIS to finance system during planning. When a project budget is approved, the PMIS sends budget lines to the finance system where they create cost centres, budget codes, or project accounting dimensions depending on the finance system’s structure. This ensures expenditure coding in the finance system aligns with programme tracking categories.
PROGRAMME MANAGEMENT SYSTEM FINANCE SYSTEM+---------------------------+ +---------------------------+| | | || Project: NG-2024-001 | Budget push | Cost Centre: NG24001 || Budget: EUR 450,000 | ---------------> | Budget: EUR 450,000 || | | || Budget Lines: | | Account Codes: || - Staff: EUR 180,000 | | - 6100: EUR 180,000 || - Travel: EUR 45,000 | | - 6200: EUR 45,000 || - Supplies: EUR 135,000 | | - 6300: EUR 135,000 || - Partners: EUR 90,000 | | - 6400: EUR 90,000 || | | |+---------------------------+ +---------------------------+ ^ | | Actuals pull | +----------------------------------------------+ | | | Expenditure sync (daily/weekly): | | - 6100: EUR 42,500 spent | | - 6200: EUR 8,200 spent | | - 6300: EUR 67,800 spent | | - 6400: EUR 22,500 spent | | | | Burn rate analysis: | | - Project 45% through timeline | | - Budget 31% consumed | | - Status: UNDERSPEND | +----------------------------------------------+Expenditure data flows from finance system to PMIS at regular intervals. Transaction-level detail is unnecessary for programme management; aggregated expenditure by budget line and period suffices. The synchronisation frequency depends on reporting cycles: weekly synchronisation supports monthly donor reporting; daily synchronisation supports real-time dashboards.
The integration mechanism varies by platform capability. API-based integration provides real-time or near-real-time synchronisation. File-based integration through CSV export/import suits systems without API access. Manual entry remains common where system integration is not feasible, though it introduces reconciliation errors and delays.
M&E platform integration
Programme management systems track what activities were implemented. M&E platforms track what results those activities achieved. Integration connects these domains so that programme managers see indicator progress alongside activity completion.
The integration typically operates through shared identifiers. Activities in the PMIS carry indicator references. When an activity completes, the PMIS notifies the M&E platform or the M&E platform queries activity status. Indicator values collected through M&E data collection reference the activities that contributed to them.
PROGRAMME MANAGEMENT M&E PLATFORM+---------------------------+ +---------------------------+| | | || Activity: Shelter dist. | Status sync | Indicator: HH receiving || Status: COMPLETE | ---------------> | emergency shelter || Planned qty: 500 HH | | || Location: Maiduguri | | Target: 500 || | | Actual: 487 || Output: 1.2 | | Variance: -13 (97%) || Indicator ref: 1.2.1 | | || | | Evidence: |+---------------------------+ | - Distribution lists | ^ | - PDM survey (n=75) | | Results pull | - GPS coordinates | +-------------------------------->| | | +---------------------------+ | Indicator 1.2.1: | - Target: 500 | - Actual: 487 | - Achievement: 97%The boundary between PMIS and M&E platform varies by organisation. Some organisations track indicators directly in the PMIS, treating M&E as embedded functionality. Others maintain strict separation, with PMIS handling implementation tracking and dedicated M&E platforms handling results measurement. The integrated approach simplifies architecture but limits analytical depth. The separated approach enables specialised M&E functionality but requires robust integration.
For further detail on M&E platform architecture, see Monitoring and Evaluation Platforms.
Grants management integration
Grant records establish the funding constraints within which projects operate. Integration with grants management ensures project budgets reflect current grant amounts, project timelines align with grant periods, and project reporting cycles match grant requirements.
When grant amendments occur, the grants management system notifies the PMIS of changed parameters: revised total amount, extended end date, modified budget flexibility rules, additional reporting requirements. The PMIS updates project records to reflect these constraints.
GRANTS MANAGEMENT PROGRAMME MANAGEMENT+---------------------------+ +---------------------------+| | | || Grant: ECHO/NGA/2024/91 | Grant data | Project: NG-2024-001 || Status: ACTIVE | ---------------> | || Total: EUR 500,000 | | Funding source: || Start: 2024-01-15 | | - Grant: ECHO/.../91 || End: 2024-12-31 | | - Amount: EUR 450,000 || | | - Period: Jan-Dec 2024 || Amendment #2: | | || - Revised end: 2025-03-31| | [Amendment triggers] || - No-cost extension | | - Timeline extended || | | - Gantt updated || Reporting schedule: | | - Report schedule sync || - Interim: 2024-07-15 | | || - Final: 2025-04-30 | | |+---------------------------+ +---------------------------+For organisations managing substantial grant portfolios, the grants management system serves as the authoritative source for funding relationships. The PMIS consumes this data rather than maintaining independent grant records. This prevents divergence between grant tracking and programme tracking.
For detail on grants lifecycle management, see Grants Management.
Offline operation and field deployment
Programme management in humanitarian and development contexts requires functionality in locations with intermittent or absent connectivity. Field staff need to view assigned tasks, update completion status, log issues, and record resource consumption without continuous internet access.
The offline capability architecture determines what operations are possible without connectivity and how data synchronises when connectivity returns.
Read-only offline caches programme data for viewing without network access. Users can see their assigned tasks, project timelines, and reference documents. Updates require connectivity. This approach suits scenarios where field staff primarily consume information and report through other channels.
Full offline enables both read and write operations without connectivity. Users view, create, and modify records offline. Changes queue for synchronisation when connectivity returns. This approach suits scenarios where field staff actively manage implementation and cannot wait for connectivity to record progress.
The synchronisation mechanism must handle conflicts where the same record was modified by multiple users during offline periods. Conflict resolution strategies include last-write-wins (simplest, loses data), merge-where-possible (attempts automatic reconciliation), or manual-review (flags conflicts for human resolution).
FIELD OFFICE HEADQUARTERS+---------------------------+ +---------------------------+| | | || Local PMIS Instance | | Central PMIS Instance || or Offline Cache | | || | | || +-------------------+ | | +-------------------+ || | Task Queue | | | | Master Records | || | - Create: 12 | | Sync when | | - Activities | || | - Update: 45 | | connected | | - Resources | || | - Delete: 2 | | <--------------> | | - Indicators | || +-------------------+ | | +-------------------+ || | | || +-------------------+ | | +-------------------+ || | Conflict Queue | | | | Conflict Log | || | - Record A: HQ | | Conflict | | - Resolution | || | modified after | | resolution | | required: 3 | || | local edit | | <--------------> | | - Auto-merged: 7 | || +-------------------+ | | +-------------------+ || | | |+---------------------------+ +---------------------------+Web-based SaaS platforms vary in offline support. Some offer progressive web app (PWA) capabilities that cache data in browser storage. Others require native mobile applications for offline access. Fully self-hosted deployments can run local instances at field locations with scheduled synchronisation to headquarters.
The data synchronisation window affects what offline modifications are possible. A system synchronising daily can support substantial offline editing. A system requiring real-time connectivity for any modification cannot support disconnected operation at all.
Field hardware constraints also affect platform choice. Web applications require modern browsers and reasonable device memory. Heavy JavaScript applications struggle on older tablets commonly deployed in field contexts. Native applications can be optimised for constrained devices but require deployment and update management.
For infrastructure considerations in field deployments, see Field Hardware Selection and Offline System Configuration.
Multi-country and consortium configurations
Organisations operating across multiple countries face additional architectural requirements: maintaining country-specific configurations while enabling consolidated reporting, managing varying access permissions by geographic responsibility, and supporting local language interfaces.
The architectural choice is between single-instance deployment with country-level partitioning or federated deployment with separate instances per country.
Single instance with partitioning maintains all programme data in one system with access controls restricting visibility by country. A global administrator sees all programmes. A Nigeria country director sees only Nigeria programmes. A regional director sees all countries within their region. Reporting aggregates across countries within a single database. Configuration differences between countries are handled through customisation within the platform.
Federated instances deploy separate system instances per country or region. Each instance is independently administered with local configuration. Consolidated reporting requires data extraction from each instance into a central analytics platform. This approach suits organisations with highly autonomous country offices but increases technical complexity and risks inconsistent data structures.
SINGLE INSTANCE MODEL FEDERATED MODEL
+---------------------------+ +---------------------------+| Global PMIS | | Analytics Hub || | | (Consolidation) || +-------+ +-------+ | +---------------------------+| | Kenya | | Uganda| | ^ ^ ^| | data | | data | | | | || +-------+ +-------+ | +------+ | +------+| | | | || +-------+ +-------+ | +------+--+ +-----+---+ +----+----+| | DRC | | Sudan | | | Kenya | | Uganda | | DRC || | data | | data | | | PMIS | | PMIS | | PMIS || +-------+ +-------+ | | Instance| | Instance| | Instance|| | +---------+ +---------+ +---------+| Role-based access || controls partition || visibility |+---------------------------+Consortium programmes where multiple organisations implement under shared funding add complexity beyond multi-country operation. Partner organisations need visibility into relevant programme components without seeing the entire portfolio. Data sharing agreements govern what information flows between organisations. The lead organisation needs consolidated reporting while partners maintain autonomy over their implementation details.
Consortium configurations in PMIS typically use one of three approaches:
Partner portal access grants partner organisations limited access to the lead organisation’s PMIS. Partners view and update their assigned activities but cannot see other partners’ work. The lead organisation maintains a single system. Partner access depends on the lead’s system availability.
Federated with integration allows each consortium member to use their own PMIS. Integration middleware aggregates data for consolidated reporting. Each organisation maintains system autonomy. Integration complexity increases with the number of partners and the heterogeneity of their systems.
Shared purpose-built instance deploys a consortium-specific PMIS that all partners access. Neutral hosting addresses concerns about any single partner controlling the system. Governance arrangements determine who administers the shared instance.
Results framework integration
Programme management connects to results frameworks that define the logical hierarchy from activities through outputs to outcomes to impact. The PMIS tracks the lower levels of this hierarchy (activities, outputs) while M&E systems typically own the higher levels (outcomes, impact). The connection between them ensures that implementation tracking serves results measurement.
A results framework for a three-year education programme might structure as:
Impact: Improved learning outcomes for primary school children in target districts
Outcome 1: Increased school attendance rates
- Output 1.1: Schools rehabilitated with adequate facilities
- Activity 1.1.1: Classroom construction
- Activity 1.1.2: Latrine construction
- Activity 1.1.3: Water point installation
- Output 1.2: Community engagement in education increased
- Activity 1.2.1: Parent-teacher association establishment
- Activity 1.2.2: Community awareness campaigns
Outcome 2: Improved teaching quality
- Output 2.1: Teachers trained in modern pedagogical methods
- Activity 2.1.1: Teacher training workshops
- Activity 2.1.2: Classroom coaching visits
- Activity 2.1.3: Learning material development
The PMIS maintains activity and output tracking. Each activity record links to its parent output. Activity completion aggregates to output achievement. Output achievement contributes to outcome measurement, though outcome-level indicators require additional data collection beyond implementation tracking.
RESULTS FRAMEWORK PMIS TRACKING LEVEL+---------------------------+ +---------------------------+| | | || IMPACT | | || (Long-term change) | Not | || | | tracked | || v | in PMIS | || OUTCOME | | || (Medium-term change) | <-------------- | || | | Linked to | || v | M&E | || OUTPUT | platform | OUTPUT || (Direct results) | <=============> | - Completion % || | | | - Quality metrics || v | Fully | | || ACTIVITY | tracked | v || (Implementation) | <=============> | ACTIVITY || | in PMIS | - Status |+---------------------------+ | - Resources | | - Timeline | | - Issues | +---------------------------+The configuration of this linkage in the PMIS varies by platform. Some platforms embed results framework management directly, allowing definition of outcomes and outputs with linked activities. Others treat the results framework as external, with activities carrying only identifier references to outputs defined elsewhere. The embedded approach simplifies configuration but limits the sophisticated indicator analysis that dedicated M&E platforms provide.
Implementation considerations
For organisations with limited IT capacity
Single-person IT departments or organisations where programme staff manage their own technology should prioritise platforms that minimise operational overhead while meeting essential requirements.
Cloud-hosted platforms eliminate server administration burden. Among these, platforms with sector focus (DevResults, ActivityInfo, TolaData) reduce configuration effort because they ship with programme management concepts pre-built rather than requiring adaptation of generic project management tools.
The integration burden is the primary hidden cost. A platform that requires custom integration development to connect with finance systems demands technical capacity that may not exist. Organisations should evaluate whether pre-built integrations exist for their finance system or whether manual data reconciliation through spreadsheet export/import is acceptable.
Start with project-level tracking before attempting programme or portfolio functionality. A single project tracked well demonstrates value and builds organisational capability. Expanding to multi-project programme management follows once the foundational tracking is established.
For organisations with established IT functions
Organisations with dedicated IT staff and existing enterprise systems should evaluate PMIS platforms against integration requirements and total cost of ownership across the application portfolio.
If the organisation has standardised on Microsoft 365, evaluate Project for the Web or Project Online against sector-specific alternatives. Microsoft integration reduces total integration burden but may require supplementing Microsoft’s project management with additional reporting or indicator tracking.
If the organisation uses an ERP system (SAP, Oracle, NetSuite, ERPNext, Odoo), evaluate whether the ERP’s project management module meets requirements before introducing a separate PMIS. ERP-integrated project management provides native financial integration but may lack programme-level functionality.
Self-hosted open source platforms (OpenProject, Odoo) become viable with IT capacity for deployment and maintenance. The absence of licensing costs and full data control benefits large deployments. The maintenance burden suits organisations with server administration capability.
For multi-country operations
Multi-country organisations must balance local autonomy against consolidated visibility.
Strongly centralised organisations benefit from single-instance deployment with country partitioning. Central IT manages one system. Country offices operate within defined boundaries. Consolidated reporting is native.
Federated organisations with autonomous country offices face higher integration complexity. Allow country offices to select appropriate tools where local requirements dominate. Invest in integration middleware or a data warehouse that aggregates programme data from heterogeneous sources for consolidated reporting.
Language requirements affect platform choice. Platforms with strong localisation support enable local-language interfaces. Platforms lacking localisation require English proficiency from all users or supplementary documentation and training in local languages.
For organisations with data sovereignty requirements
Programmes handling sensitive data or operating in contexts with data residency requirements need deployment options that keep data within appropriate jurisdictions.
Self-hosted platforms (OpenProject, TolaData, Odoo) can be deployed on infrastructure within any jurisdiction. The organisation controls physical data location. This addresses data sovereignty at the cost of operational complexity.
Cloud platforms vary in data residency options. Microsoft offers regional datacenter selection including European Union. Sector-specific platforms typically operate from US or EU datacenters. Evaluate whether the platform’s data location meets programme requirements and donor stipulations.
For programmes with protection data or other highly sensitive information, evaluate whether PMIS should contain that data at all. Aggregated activity tracking in the PMIS with sensitive case data held in separate, appropriately secured case management systems may provide better risk management than attempting to secure all data within a single system.
Protection data in PMIS
Programme management systems are not designed for sensitive protection data. Activity records like “conducted GBV case management” are appropriate. Individual case details are not. See Safeguarding Case Management Security for appropriate handling of protection data.