The Multi-Actor Approach tool

The MAA tool: multi-actor engagement as a traceable workflow

main tellingdepth: standard3 min markdown

The multi-actor approach asks farmers, advisors, authorities, researchers and citizens to shape a pilot together. The Multi-Actor Approach (MAA) tool is where PoliRural+ pilots record that work, so it can be checked and reused later.

Where it comes from

Social InnoLabs first developed the tool in the Cities2030 project. In PoliRural+ it is being redesigned for many different labs and pilots, with new programmes, work entities, charts and communication engines. D5.1 describes the new architecture (D4.1 §2.1.1).

What a pilot team does in it

• registers and classifies stakeholders, and assigns roles and permissions;
• links stakeholders and members to programmes or work entities;
• defines objectives and sub-objectives, and records indicators and inputs;
• adds configurable attributes, such as sector, organisation size or urban/rural profile, and charts how stakeholders are distributed across them.

These records feed WP5 stakeholder mapping, RAP preparation, pilot validation and feedback to WP3 and WP4 (D4.2 §3.9).

Status in the Beta: in pilot use

The PoliRural+ workspace follows the project’s work-package structure, including WP5 and nine pilot work entities. In the Beta it holds more than 300 registered users, 40 work entities, about 150 classified stakeholder profiles, 49 objectives and 40 input progress records. D4.2 takes these figures as evidence that the tool is already used to coordinate pilot and work-package activities, not only shown in demos (§3.9, §6.1).

The built-in Ramon AI assistant searches for work entities, users, stakeholders and objectives and proposes new ones. In pilot testing it extracted stakeholders and objectives from pilot documents for users to validate, which cut administrative effort (§6.3). Nothing is created until a user confirms it. Technically, the tool is a web application with an Angular front end and a NestJS API back end.

Limits named in the sources

D4.2 names three gaps. Social spaces appear in the navigation but have no content yet. Stakeholder assignments still need to be completed in the same way across all nine pilots. The pilots also need a common attribute vocabulary. Fuller WP5 validation evidence will be reported in D4.3. The pilots’ revised RAPs agree that tools like the MAATool add value, but they also report barriers from limited digital literacy and interface complexity, and they call for simplification and targeted training (D2.3 §5.2).

Beyond the pilots

D4.2 describes the MAA tool supporting coordination in INTERESH’s soil-health Living Labs. There it structures stakeholder profiles, objectives, roles and progress records among farmers, advisors, researchers and authorities (§9.3).

How-to: Using the MAA tool step by step.

How to use the MAA tool: from a stakeholder list to tracked objectives

another tellingdepth: standard2 min markdown

When to use it: your pilot needs one shared record of who takes part, what they committed to, and how far it has got.

What you need

• An invitation. The pack gives no public address. Users are tied to an e-mail address; someone can create you as a “representative” user and invite you by e-mail, and you stay “pending” until you confirm it (D5.1 §4.2). Ask your pilot lead or the WP5 team.
• Your pilot’s stakeholder list (pilots’ T2.1 stakeholders were imported at set-up, D5.1 §4.3), its objectives and pilot documents.

Steps

1. Confirm your account and open the PoliRuralPlus programme. Its work entities mirror the work packages; WP5 uses the depth “work packages → pilots → activities” instead of “action plans → actions → tasks” (D5.1 §4.2).
2. Register stakeholders in your pilot’s work entity: classify them and assign roles and permissions (D4.2 §3.9). A public stakeholder can be found and invited by other programmes; a private one cannot (D5.1 §4.2).
3. Fill in the extra attributes the programme defines, such as sector, organisation size or urban/rural profile. They drive the distribution charts.
4. Define objectives (KPIs, goals or milestones) and assign them to work entities.
5. Link an indicator to each non-aggregated objective: integer or decimal, increasing or decreasing, static or variable value (D5.1 §4.2).
6. Record inputs: each new value with a date and an optional comment. These updates move the objective forward.
7. Let Ramon draft, then decide. The built-in AI assistant extracts candidate stakeholders and objectives from pilot documents; you validate them before anything is created (D4.2 §3.9, §6.3).

What you get

Searchable stakeholder and member registers, pilot and work-package views, objective progress tables, attribute-based charts and a communication history. D4.2 names them as evidence for RAP documentation, engagement summaries and testing reports (§3.9). In the Beta workspace this already covers more than 300 users, 40 work entities and 49 objectives.

Watch out

• Social spaces appear in the menu but are still empty at programme and WP5 level.
• Stakeholder assignments are not yet complete in the same way across all nine pilots, and there is no common attribute vocabulary yet, so compare charts between pilots with care.
• Fuller WP5 validation evidence and export functions are planned for D4.3 (D4.2 §3.9).

A recorded online workshop (22 July 2024) walked pilots through the application; ask WP5 for it (D5.1 §4.4.1). The method behind the tool: the multi-actor approach.