Agree actions and responsibilities

Step 8 of 12 Measure Planning

← Select measure packages

SUMP overview

Prepare for adoption and financing →

The package agreed in the previous step is still a list of good intentions. This step turns it into a programme somebody is accountable for, with every action written down against an owner, a timeline, the resources it needs and the decision it waits on. In the outskirts that is more than paperwork. The organisations that have to deliver the package sit in different administrations with no shared line of command, so the only thing holding the programme together is what each of them has agreed to in writing, in front of the others.

Before you start this step

The measure package your coalition settled on, with the reasoning for the bundle recorded, not only the list of measures.

The indicator agreed for each measure, and a first answer on who is in a position to collect it.

A current view of who is actually in the coalition you built, including any partner who joined late and any who quietly stopped attending.

Who can commit to what

Before assigning anything, be honest about what each organisation at the table is able to promise. The stakeholder overviews the DREAMS living labs drew up (Deliverable 6.1) sorted local partners into a small set of role types, and that sorting works as a quick sanity check on any action list.

Decision-maker

Can authorise the action and carry the political weight of it. In the labs this is a municipality, a district or a regional authority.

Service provider

Runs the thing once it exists. Usually a commercial operator or a public transport company.

Project-supporting body

Contributes funding, data, staff or a mandate that helps, but cannot decide alone.

Advisory partner

Brings expertise or local knowledge without holding a lever.

Beneficiaries

The residents and associations the measure is for. They hold no formal role at all unless the programme gives them one.

The reason to sort them is that these roles rarely line up neatly in a periphery. The Paris lab records two decision-makers rather than one, the municipality of Évry-Courcouronnes for what happens in the street and Île-de-France Mobilités for what happens on the transport network, with the regional and departmental authorities in supporting roles and the operator Pony as the service provider. Around Munich, the neighbouring cities of Geretsried and Wolfratshausen sit alongside the regional transport association and two commercial car-sharing operators, and none of them reaches across the whole area on its own. This is the split governance you mapped at the outset arriving at the moment it costs something. Where two bodies each hold part of the mandate, decide which one moves first and write that down, because an action with two owners has none.

What one action has to carry

SUMP asks planners to describe every action in the plan and then agree responsibilities, priorities and timing for them. The description that survives contact with delivery is a specific one. Vague wording is where a programme quietly loses its owner, because an action assigned to "the municipality" or "the operator" belongs to nobody in particular. Work through the measures in your package one at a time, and give each action all six of the following.

• The action itself, in a sentence a reader outside the project would understand without the plan open beside them.
• One owning organisation, and inside it a named team or role rather than an institution in the abstract.
• What the others contribute, recorded next to the owner, so a dependency on another body is visible before it becomes a delay.
• A start and an end, anchored to the decision or approval the action waits on where there is one.
• The resources, meaning staff time, capital, and the running cost once the launch is over, which is the one most often left out.
• The indicator you already chose to judge it by, together with whoever will collect it.

Write down what happens if a partner cannot deliver

A programme built across organisations has no hierarchy to fall back on, so it needs its own safety net. For every action that depends on more than one body, agree now what the fallback is if the commitment does not arrive, who gets told, and at what point the action is formally reviewed rather than quietly abandoned. Cross-boundary programmes rarely fail at a decision. They fail in the gap between one organisation finishing its part and another noticing.

One programme, action by action

Living lab Paris, Évry-Courcouronnes

The Paris lab set out to close last-mile gaps along the Tram 12 corridor with new shared mobility stations, discounted memberships and clearer station signage. Rather than record who was involved, it broke each intervention into its working tasks and put a named partner and a date window against every one. Identifying candidate station locations, reading the local demand, preparing the physical installation and then evaluating it each got their own line, with the two research partners leading and the operator named beside them on the tasks that could not move without a fleet. The signage work ran the same way and drew in the municipality and the transport authority at the point where a design had to be validated, not at the start.

The useful artefact there is not the list of partners but the breakdown. A programme written at the level of whole interventions hides the handovers, and handovers are where periphery projects stall, because the next pair of hands usually belongs to a different employer. Deliverable 6.1 sets out the Paris timeline in full and is worth reading as a format rather than as a case.

The Utrecht plan adds a column worth borrowing. Next to each activity and its lead, it states what is expected from each of the other partners, so the operator, the municipality and the cyclists' union each read their own commitment on the same line instead of inferring it from the lead's (Deliverable 5.1). Expectations recorded that way are much harder to forget and much easier to chase.

Test the assumption before you fix it

An action list allocates responsibility. It does not check whether the allocation is one the other organisations recognise, and in a coalition without hierarchy an unrecognised assignment is just an action that will not happen. ResiMob, built in the DREAMS project's governance work, is a fast way to test that while the programme is still a draft. It asks the actors in a local shared mobility system, meaning private companies, public and municipal institutions, users of the services, residents who do not use them and third sector organisations, to rate both how involved each of them is today and how involved each of them ought to be, across nine components of a resilient, inclusive and responsible shared mobility ecosystem. The answers are drawn as a radar chart that can be filtered by city, by who is answering and by which actor is being rated.

Two features of that picture bear directly on this step. A wide gap between the current shape and the wished shape marks a role the group thinks is underfilled, which is a candidate for a new commitment in your programme. A wide spread between respondent groups on the same component marks an assumption about responsibility that has never been tested in conversation, which is a candidate for an agenda item before anything is signed. ResiMob will not settle who should do what. It makes the disagreement specific enough to be worth an hour of the coalition's time.

ResiMob

A stakeholder survey and radar chart developed in DREAMS. Compare how involved local companies, authorities, users and civil society are in the shared mobility system today with how involved they ought to be, and see where the local view holds together and where it splits.

Open the tool →

Run it while the assignment is still open to change. What you carry out of this step is the thing the next one has to cost, fund and put to a formal vote, and a commitment that was never really agreed will not survive that.

By the end of this step you should be able to

Name one owning organisation, and a team inside it, for every action in the package, with no action carrying two owners.

Point to the agreed fallback for each action that depends on a body outside your own administration.

Show that the roles you assigned are the roles the other organisations recognise, because you have asked them rather than assumed it.

Hand the programme to the financing step with resources and running costs attached, not only capital.

Go deeper

The EU project CH4LLENGE produced four practitioner kits on the hardest parts of SUMP work, and the one for this step is institutional cooperation. Its Institutional Cooperation kit covers identifying the partners you need, drawing in the ones who would rather not be involved, defining their roles, and agreeing the rules, the resources and the responsibilities that go with them. For current work on the same problem, the DUT sister project CO/ALIGN studies how coalitions of civil society organisations, multi-level urban governments and knowledge institutions hold together, and is assembling a European atlas of the tactics that let them scale up from a single street.

Sources and further information

EU SUMP Guidelines, Second Edition (Rupprecht Consult, 2019), Step 8, Agree actions and responsibilities.

DREAMS Deliverable 6.1: stakeholder overviews and role types across the living labs, and the task-level intervention timelines including Paris.

DREAMS Deliverable 5.1: set-up of the living labs, including the Utrecht activity plan and its per-partner expectations.

ResiMob: the DREAMS stakeholder survey and radar chart for testing agreed roles.

Zuständigkeiten festlegen, German national SUMP portal, Bundesministerium für Verkehr.

← Select measure packages

SUMP overview

Prepare for adoption and financing →