Most technical assistance is delivered by teams that combine disciplines: law and economics, engineering and safeguards, data and public finance. The risk lies less in any one member than in the interfaces between them and in who answers for the whole. This page sets out how teams are composed, where accountability breaks, how composition changes propagate through a work plan, and what the institutions that commission and receive the work need to see.
GCRI · Established · service level R0
A multidisciplinary team is a group that combines disciplines such as law, economics, engineering, safeguards, data and public finance to deliver technical assistance. Risk sits less in any one member than in the interfaces between them and in who answers for the whole, so each deliverable needs one accountable holder and written interface agreements.
The jurisdictions that hold authority over this question: countries, their first-level divisions and capitals, shown for the Gulf as an example geography for this subject.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Team formation · Assignment pool · Quarter 3
| Team lead | Disaster risk management | None declared | Confirmed |
| Hydrologist | Flood modelling | Declared, managed | Confirmed |
| Data engineer | Pipelines | None declared | Invited |
| Reviewer | Independent | None declared | Confirmed |
Interdisciplinary assignments and accountability. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Each discipline works to its own standards and vocabulary. Gaps open where an engineer's design assumes a safeguard measure no one costed, or an economist's model assumes a legal power the lawyer has not confirmed.
When a deliverable has several contributors and no single accountable holder, quality checks fall between them. A named team leader with documented authority over content and schedule is the usual remedy, and often missing.
Members leave, are reassigned or are replaced mid-assignment. Each change loses context, relationships with counterparts and undocumented decisions, and the replacement inherits work they did not scope.
One late input, such as a survey or a legal opinion, holds back every deliverable that depends on it. Downstream experts wait or proceed on assumptions, and rework compounds the original delay.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Responsibility matrix | A chart, such as RACI, assigning who is responsible, accountable, consulted and informed for each task. |
| Interface agreement | A written agreement between workstreams on what each hands to the other, when and in what form. |
| Critical path | The sequence of dependent tasks that sets the shortest possible completion time. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Deliverables with a single accountable holder | percent of deliverables | per work plan | Inception reports, responsibility matrices | DECLARED |
| Disciplines required against disciplines staffed | ratio | per assignment | Terms of reference against team roster | REPORTED |
| Documented interface agreements between workstreams | count per assignment | per work plan | Inception and work-plan records | REPORTED |
| Team member changes during the assignment | count per assignment | per assignment | Contract variation records | OFFICIAL |
| National and local expert input | percent of expert person-days | per assignment | Timesheets and contract records | REPORTED |
| Gender composition of expert teams | percent of team members | per assignment | Team rosters | DECLARED |
| Schedule variance on team deliverables | days | per deliverable | Work plan against acceptance dates | OBSERVED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| World Bank Implementation Completion and Results Reports | Records of team, implementation arrangements and lessons on delivery | Public documents under the World Bank access to information policy |
| OECD DAC Evaluation Resource Centre | Published evaluations of programmes, including team and management arrangements | Public reports, terms per evaluating agency |
| EU Results Oriented Monitoring reports | Structured monitoring of EU-funded actions, including implementation and management findings | Published reports, European Commission reuse terms |
| IATI Datastore | Participating organisations and roles in each activity | Open, licence declared per publisher |
| National audit office performance audits | Findings on the management and accountability of consultancy teams | Public records, terms per audit office |
Nexus Agency prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Client project implementation unit or programme director | Whether the proposed team covers every discipline the work requires and names who answers for each deliverable | Composition matrix and responsibility matrix against the terms of reference |
| Funding agency task team leader | Whether a mid-assignment team change keeps the competence and continuity the contract assumed | Substitution evidence and continuity plan |
| Employing firm or institution management | Whether it can field and retain the team for the assignment's duration | Availability commitments and interface register |
| Programme steering committee | Whether delays on one workstream require rescoping the others | Interface register and schedule variance on dependent deliverables |
Teams fail when each discipline produces its own report and nobody integrates them, when assumptions made by one member are invisible to another, or when responsibility is shared so widely that no one answers for the result. Status differences between disciplines can silence the people closest to the affected communities.
Well-run teams agree a shared problem statement and a common set of assumptions early, make interfaces between work packages explicit and schedule integration as work in its own right rather than an afterthought.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.