Contracting unit: - Office of the Chief Scientist, CGIAR System Organisation

Budget Ceiling: - USD 30,000 (all-inclusive; competitive open call)

Duration: - 6–8 weeks

2027 milestone: - Blueprint endorsed; build procurement decision made

Delivery lead: - Portfolio Performance and Results Team (PPT)

Oversight: - Steering Group (Office of the Chief Scientist, DTA, Digital)

Deadline for Applications: - 8 September 2026, 23:59hrs (Paris time GMT+2)

Background

The Performance & Results Management System (PRMS) is CGIAR's core infrastructure for portfolio planning, results reporting, quality assurance, adaptive management, risk management and accountability. It was identified in the CGIAR Performance and Results Management Framework as a common system housing planning, theory of change management, stage-gate decision points, and annual reporting — with linked datasets, an integrated dashboard for funders and management, and access aligned to international standards. A February 2021 Accenture fit-for-purpose assessment translated this into implementation requirements: integrated business applications, standardized data definitions across CGIAR systems, and comprehensive onboarding of end users. CGIAR invested approximately USD 800k per year to build and run that system during the period 2022-25, with joint Independent Advisory and Internal Audit review during rollout to ensure delivery against specification.

The PRMS was built for a context of relatively stable institutional requirements: a defined set of manual inputs, largely from Window 1/2 funding, processed sequentially — each stage waiting for the previous — to produce a predetermined set of outputs on a predictable cycle. Bespoke requests that fell outside those predetermined outputs required specialists to extract value case by case. That design was rational for the conditions in which it was built. Five shifts prompt a redesign.

The first is the nature of demand. The portfolio now requires dynamic, on-demand, user-defined outputs — some anticipated, many not. New business requirements arrive at unpredictable intervals: a GST decision requiring real-time performance data for resource allocation, a donor wanting a bespoke cut across Programs, an AI tool needing to interrogate the data layer directly. A system with predetermined outputs cannot serve this.

The second is the scope of what the system must hold. Window 3/bilateral funding — around 1000 non-pooled projects — is heterogeneous in structure, language, and reporting logic. W3/bilateral data cannot be pre-programmed into the system; it is a different problem type, and the current architecture has no way to accommodate it.

The third is the ability to orchestrate. CGIAR now deploys operational AI tools — for example SNAP, the zero-draft generator, the QA helper, the Progress Tracking Solution — that need to query, submit to, and coordinate across the system. The current PRMS is not orchestrable: its components are not designed to be called, sequenced, or managed by an AI agent. A system that AI can understand and act on any layer is a key requirement.

The fourth is the multiplicity of data sources the system must draw on. Portfolio evidence already sits across many instruments and repositories — among them legacy CRP and Initiative results, current Program and Accelerator results, Plans of Results and Budget (PoRB), Projected Benefits, the Impact Compendium, CGSpace, AnaPlan and others — each with its own structure and logic, with limited interconnections.

The fifth is the technological revolution in data management. The maturing of AI and large language models has changed what is possible: data no longer has to be captured through fixed forms and rigid fields to be usable, and outputs no longer have to be predetermined and assembled by hand. This reframes the redesign itself — not a faster version of the old model, but a shift to more flexible, AI-native handling of data that cuts duplication, lowers effort, and can generate higher-quality outputs on demand while maintaining core security safeguards.

The new PRMS must be modular, reconfigurable, and interoperable by design — not simply cheaper to build, but cheaper to run and extend, with a clear view of the trade-off between reduced human effort and the real costs of AI-driven processing at scale.

Two developments in 2026 show what this looks like in practice. The CGIAR Progress Tracking Solution — launched in July 2026 — demonstrates a possible target architecture: AI-assisted, modular, with a human validation layer, open enough for users to connect their own systems via API. The June 2026 GST-endorsed Guidance Note on Program/Accelerator-level prioritization establishes that actual performance against theories of change will directly inform W1/W2 fund allocation from 2026 onward: PRMS data must be queryable in real time to feed consequential resource allocation decisions, not compiled into static reports after the fact. Together, they define what fit for purpose now requires.

Purpose

This commission produces an architectural blueprint for a rebuilt PRMS — the design basis for a subsequent build investment. It is not a developer-ready technical specification. It is the front end of a two-stage process: design now, procure and build against it. Steering Group endorsement of this blueprint will be the decision gate for the larger investment.

The starting point is not the technology but the people the system serves — funders, senior leadership and governing bodies, Program and Accelerator directors, Centers, and external partners — and the outputs they need, from stabilized reports and dashboards to on-demand answers tailored to a specific question. The design works back from those needs to the data the system already holds, and it must make the system materially lighter to feed — less manual entry, less duplication, less double reporting — not only cheaper to run.

The design target is a system that is orchestrable: modular, reconfigurable, and interoperable, built so that AI agents can understand and operate across any layer — or so that any process can run without AI, depending on the risk appetite and the requirement. A result linked to a causal pathway is the atomic unit; everything else is an expression of it. Report once, use many times. The system must function as a data layer that CGIAR tools and authorised external actors can query, contribute to, and act on — not a system that only produces predetermined outputs for predetermined audiences.

The blueprint must address constraints: that replacing human effort with AI-driven processing shifts cost rather than eliminates it, and that AI operating costs at scale must be designed for; and that Center and Program adoption has been suboptimal, and the design must address why. Both are in scope. The blueprint must be specific enough to brief the Performance and Results Management Steering Group, scope a build procurement, and hold a development team accountable.

Objectives

  1. Map the demand the system must serve. Identify the priority users and uses — internal and external — and the outputs each needs, from those already mandated by CGIAR governance to the on-demand, tailored outputs that AI now makes possible. Distinguish what the system already delivers well from what users cannot currently obtain.
  2. Take stock of the foundational building blocks the portfolio already runs on — for example the Theory of Change, the Projected Benefits model, the Results Framework and its 3 indicator tiers, PoRB/PoD planning instruments — and assess their fitness as the base for a redesigned system rather than starting from a blank slate.
  3. Characterize the data supply and its fragmentation — what is entered by hand versus captured automatically, and what lives across CGIAR, donor, and Center systems — and consider the growing overlap between monitoring data and science or project data under FAIR. Set out what this implies for a system that draws on existing sources rather than re-collecting data during each reporting cycle.
  4. Define the connecting layer between demand and supply — the core of this commission. At the level of principle and direction, set out how a result linked to a causal pathway becomes the atomic unit that is reported once and reused many times; how the layer is made FAIR, API-first, and orchestrable so that CGIAR tools and authorised external actors — including AI agents — can query and contribute to it; and how heterogeneous W3/bilateral data is accommodated without being forced into a W1/W2 mold.
  5. Show how the redesign lightens the load — and where it does not. Explain how it may reduce fields, duplication, and double reporting and shift effort from manual data entry toward data interoperability, while being honest about the trade-offs, including AI operating costs at scale and the points where human judgment must remain.
  6. Set out the direction of travel and a phased path — what is foundational and should be settled now versus what can be resolved at the build stage, including a costed view of the interim 2027 release and the fuller rebuild. As part of this, diagnose at a strategic level why Centers and Programs have historically, to different extents, routed around PRMS, and what the new system must do differently to earn adoption.

Scope and Constraints

This is a conceptual design commission. The consultant produces the architectural blueprint and roadmap, with the Performance and Results Management Steering Group providing oversight and independent challenge. While security, access controls, audit trails and availability are core aspects of the future system, detailed technical specification — schema definitions, API contracts, and migration mechanics — is deliberately out of scope at this stage: the blueprint establishes direction and principle, and the build phase resolves the detail.

Ready by 2027 means: blueprint endorsed by the Steering Group and a build procurement decision made — not full system deployment. Specific PRMS capabilities needed for the 2027 reporting cycle will be identified in the roadmap and may be delivered as an interim release against the existing system while the rebuild proceeds. The costed build roadmap must give PPT and Centers a concrete transition path for modules currently under active management — including the Planning Module and POD — specifying which planned enhancements should continue during the review period and where enhancement work should pause pending the interim 2027 release, so teams are not left to decide this unilaterally while the review is underway.

W3/bilateral data integration — where permitted by Centers — is within scope. It is a distinct architectural problem that the blueprint must address — not a future phase or an edge case. The heterogeneity of non-pooled project data, the challenge of connecting it to the CGIAR results hierarchy, and the implications for Center-level data ownership and access are design questions the consultant must answer.

Center and Program adoption is a governance and change management challenge, not an architectural one. The blueprint will diagnose it and specify design requirements that reduce friction, but the Steering Group — not the consultant — must own the adoption strategy.

Given that PPT leads both delivery and the Steering Group secretariat, the blueprint will be subject to independent technical review by at least two Steering Group members with relevant technical expertise before endorsement. This is a process requirement, not optional.

Deliverables

  • Architectural blueprint.
  • Costed build roadmap.
  • Performance and Results Management Steering Group briefing deck.

Methodology

  • Review of PRMS technical documentation, AI tool dependency evidence, MELIAF Interoperability Framework, March 2026 operational incident record, enhancement request history, and existing API documentation and agent integration work produced by the PRMS infrastructure team.
  • Interviews with PRMS infrastructure team, PPT AI tool developers, MELIAF workstream leads, Center MEL leads, and Center representatives who have actively worked around PRMS. The interview set must include demand-side users, not only the supply side.
  • Co-design sessions with PPT to validate architecture decisions.
  • Independent technical review of draft blueprint before finalisation — reviewers nominated by the Performance and Results Management Steering Group.

Timeline

Duration: 6–8 weeks

  • Weeks 1–2: Document review, interviews, co-design sessions
  • Weeks 3–5: Blueprint drafting
  • Week 6: PPT review and iteration
  • Weeks 7–8: Independent technical review, revisions, Steering Group briefing

Required Expertise

  • Senior-level expertise in data architecture and API design for complex, federated data environments — including experience designing for AI orchestration and agentic access patterns.
  • Advanced understanding of AI/ML pipeline requirements — practical understanding of what LLM-based and agentic tools require from upstream data infrastructure, including cost modelling at scale.
  • Deep experience in MEL and risk-informed systems in international development — results frameworks, theory of change, indicator management, and bilateral reporting structures.
  • Proven ability to advise on organizational change and adoption in federated, multi-stakeholder settings.
  • Track record producing architectural blueprints that non-technical leadership can act on and developers can build against.
  • Strong capacity to translate user, governance, and reporting needs into system and data requirements — a service-design sensibility that starts from what users must be able to answer.
  • Experience with CGIAR, multilateral research organisations, or comparable federated institutional environments is an advantage.

Required application documents

·       A technical proposal, including:

  • Updated CVs and a cover letter explaining how the consultant’s qualifications and experience meet the requirements of the assignment;
  • A short approach to the work, maximum 2–4 pages, outlining how the consultant proposes to address the objectives and deliverables in these TORs, with reference to comparable assignments that demonstrate the required expertise.

·       A financial proposal in USD, quoted as a lump sum and supported by a cost breakdown by level of effort per deliverable. Combine both technical and financial proposal in one document.

Evaluation and communication

CGIAR places strong emphasis on ensuring that the objectives of the PRMS Architectural Redesign Blueprint are met. Proposals will be assessed on technical merit and value for money. Only pre-selected candidates will be contacted.

Annex 1: CGIAR Performance and Results Management Framework’s definition of the

Performance and Results Management System (December 2020)

Building on investments made in the current phase of CGIAR research programming, a comprehensive, mature and accessible Performance & Results Management System (PRMS) that encompasses planning, monitoring, and reporting will provide robust information upon which to take informed decisions. It will provide:

•  Practical services aligned to meet learning, accountability and resource mobilization objectives,

•  Dashboards open to Funders and partners, with access to the full set of underlying quality-checked data, including communications-focused products capturing collated evidence of CGIAR contribution to change (e.g. outcome/impact case reports).

•  Alignment with international standards such as IATI (International Aid Transparency Initiative).

Key PRMS features

The CGIAR PRMS will feature:

•   A common system housing plan of work and budget, theory of change management, stage-gate decision points, and annual reporting processes. It will allow real-time data collection and day-to-day portfolio and Initiative management.

•   Key data sets (results, plan of work and budget, grant, finance, stage-gate specific e.g. Scaling Readiness) will be increasingly linked, for example through CLARISA: CGIAR Level Agricultural Results Interoperable System Architecture, a web service that harmonizes data from across the CGIAR).

•  Interface and exchange with big data and partner data sets (e.g. WIPO Green and the International Treaty on Plant Genetic Resources for Food and Agriculture) will increase. CGIAR will publish relevant data through IATI. CGIAR Performance and Results Management Framework 2022-2030 CGIAR System Organization Page 16 of 20

•  CGIAR’s digital knowledge base will make better use of linked data through Knowledge Graphs, and

will use the SDG Interface Ontology to better link its contribution to impact with that of partners.

•  An integrated dashboard will draw from relevant data sets to provide transparent data and insights on

CGIAR geographic and thematic presence, contribution to change, spend and partner network.

Users

Target users of the PRMS include CGIAR staff for day-to-day Initiative management and reporting, portfolio management and resource mobilization, and Funders and partners to access evidence of CGIAR thematic and geographic presence and progress against stated objectives such as the SDGs.

Security, hosting, maintenance and support

The PRMS will incorporate:

•  Secured infrastructure,

•  Cloud hosting,

•  CGIAR Active Directory integration for user provisioning and account management,

•  Access control through Multi-Factor Authentication,

•  Single Sign On,

•  Tiered support and maintenance approach aligned with CGIAR’s IT support model.

All applications must be submitted online by clicking the 'Apply' button below before 11:59 PM CET on 08 September 2026.

If you require assistance or face challenges in submitting your application, please email smo-bidding@cgiar.org with the position title in the subject line. Applications submitted through smo-bidding@cgiar.org will NOT be accepted.

Please ensure your resume and cover letter are in English and does not contain your marital status, age, or photograph. Documents provided in a language other than English will not be considered.

CGIAR is committed to fair, safe, and inclusive workplaces. We believe that diversity powers our innovation, contributes to our excellence, and is critical for our mission. We offer a multi-cultural, multi-color, multi-generational, and multi-disciplinary, collegial working environment. We consciously create an inclusive organization that reflects our global character and commitment to gender equity. We, therefore, encourage applicants from all cultures, races, ethnicities, religions, sexes, national or regional origins, ages, disability status, sexual orientations, and gender identities.

Only shortlisted applicants will be contacted. 

We look forward to hearing from you! 

At Impactpool we do our best to provide you the most accurate info, but closing dates may be wrong on our site. Please check on the recruiting organization's page for the exact info. Candidates are responsible for complying with deadlines and are encouraged to submit applications well ahead.
Before applying, please make sure that you have read the requirements for the position and that you qualify. Applications from non-qualifying applicants will most likely be discarded by the recruiting manager.