View source for Manage implementation

{{SumpStep/top|step=10|phase=4|title=Manage implementation}}<div class="sump-intro">
Phase four is where the plan stops being a document. The measures adopted in [[Prepare for adoption and financing|the previous step]] now have to be detailed, contracted, built and switched on, by departments and organisations that each hold one piece of the work. SUMP asks for two things here. The responsible bodies plan the technical detail of their own projects and procure whatever has to be bought, and somebody coordinates the whole programme so that the pieces arrive in an order that works. In the outskirts the second is the difficult one, because the pieces belong to different employers and the slowest of them sets the pace for everyone.
</div>

<div class="sump-prereq">
<div class="sump-prereq__title">Before you start this step</div>
<div class="sump-prereq__list">
<div class="sump-prereq__item"><div class="sump-prereq__box"></div><div class="sump-prereq__text">The adopted plan with the budget decision behind it, because delivery that starts before the vote is delivery nobody is obliged to honour.</div></div>
<div class="sump-prereq__item"><div class="sump-prereq__box"></div><div class="sump-prereq__text">A written list of what each first-year measure depends on outside your own administration, meaning permits, tenders, third-party works and the dates any of them expire.</div></div>
<div class="sump-prereq__item"><div class="sump-prereq__box"></div><div class="sump-prereq__text">Someone whose job is the whole programme rather than one measure of it, with protected time for it, since the handovers between organisations are what needs watching.</div></div>
</div>
</div>

== The critical path is not the construction ==

<div class="dreams-lab">
<div class="dreams-lab__tag">[[Living_Labs/3|Budapest, Rákosmente]]</div>
Putting a public bike-share into an outer district of Budapest meant running two tracks in parallel for well over a year before anything appeared on a street. One track was the service. The district authority, the city transport authority, the national transport research institute and the university worked through legal requirements, then folded the pilot area into the city's own next-generation bike-share framework, then negotiated and signed a service contract. The other track was the stations. Macro-level siting, then detailed micro-siting, then a contract with one firm for the civil engineering design, then permits and construction planning, then authorisations from the district, the transport authority and the city roads body, then a second contract with a second firm to build them. Construction itself took the last quarter of the programme.
</div>

Two things in that account are worth taking seriously. The first is the proportion. Almost all of the elapsed time went on legal work, siting, permissions and contracting, and the visible part, putting stations in the ground, was the short bit at the end ([[Publications/5|Deliverable 5.1]]). A delivery plan that schedules the construction carefully and treats the permissions as an administrative preliminary has the wrong shape and will slip.

The second is what happened to the timing. The launch depended on the readiness of the citywide bike-share extension, which a different organisation was rolling out, and when that slipped the lab's operating period was cut from six months to three. The content of the pilot survived intact. What suffered was the comparison, because a shortened window changes which season the service is judged in ([[Living_Labs/3|the Budapest lab's own account]]). That is the characteristic shape of a periphery delay. The measure still gets delivered, and the cost of the delay lands on the evidence rather than on the thing itself.

<div class="dreams-callout">
<div class="dreams-callout__label">Name the dependencies you do not control</div>
Write down, for each measure, every event outside your own administration that has to happen first. A neighbouring authority's tender cycle, a utility's works, a permit from a roads body, another organisation's system launch, an operator's concession renewal. Give each one an owner inside your programme whose only job is to ask about it regularly, and agree now what you will do if it moves, including whether the measurement window moves with it. A dependency that nobody is watching is not a risk you have accepted, it is one you have not noticed.
</div>

== Procurement decides what you actually get ==

Most of what a mobility plan promises in the outskirts is a service somebody else operates, so the contract is the measure. The DREAMS review of shared mobility governance is blunt about what goes wrong. Operators do not always honour what they agreed, whether that is the number of vehicles kept in an area or the transmission of operating data, and they tend to drift back towards the dense parts of their territory. Checking compliance costs the authority staff time, and without penalties there is little reason for an operator to prefer the thin area. The free-floating market in particular is volatile, with operators arriving, merging, withdrawing and failing, which matters most in sparsely populated areas where profitability was uncertain to begin with ([[Publications/3|Deliverable 2.2]]).

Four things follow for the specification. Write the service level as something observable in your area rather than as a fleet total, since vehicles registered to a city are not vehicles available in an outskirt. Make data transmission an obligation with a named format and frequency, because everything the [[Monitor adapt and communicate|monitoring step]] needs either arrives under this clause or does not arrive. Budget the staff time to check compliance and attach a consequence to failing it, as a condition nobody verifies is a condition nobody meets. And provide for the operator disappearing, since in a thin market the replacement you would turn to may not exist.

== Running the delivery ==

<div class="sump-sequence-wrap">
<div class="sump-seq-item"><div class="sump-seq-label">Sequence by dependency, not by ambition.</div><div class="sump-seq-desc">Order the first year around what unblocks other work rather than around what is most visible. A permission chain that runs nine months has to start before a measure that takes nine weeks, even if the short one is the one people are waiting for.</div></div>
<div class="sump-seq-item"><div class="sump-seq-label">Start the slow contract first.</div><div class="sump-seq-desc">A service agreement and a construction contract are separate procurements on different clocks, and they rarely need to start together. Work backwards from the launch date to find which one has to be signed first.</div></div>
<div class="sump-seq-item"><div class="sump-seq-label">Fix the before-state before the works begin.</div><div class="sump-seq-desc">Once delivery starts the situation you were going to compare against is gone. Collect the last baseline readings for each measure while the ground is still untouched, using the indicators already agreed for it.</div></div>
<div class="sump-seq-item"><div class="sump-seq-label">Hold a standing coordination point.</div><div class="sump-seq-desc">A short regular meeting across the delivering organisations, with the dependency list as its agenda rather than a round of progress reports. In a programme with no shared line of command this meeting is the coordination.</div></div>
<div class="sump-seq-item"><div class="sump-seq-label">Re-check what other people are doing.</div><div class="sump-seq-desc">External dependencies move quietly. Ask about each one at every coordination point and record the answer, so a slip surfaces while there is still room to respond to it.</div></div>
<div class="sump-seq-item"><div class="sump-seq-label">Agree in advance what a slipped date triggers.</div><div class="sump-seq-desc">Decide which measures may be resequenced, which cannot move without a fresh decision, and who takes that decision. Settled beforehand, a delay becomes a choice. Settled afterwards, it becomes drift.</div></div>
</div>

== Test small before you build permanent ==

The Vienna lab went the other way entirely. Instead of building, it reactivated an underused space in Liesing as a flexible activity hub, with cultural and food offers, and invited residents and local initiatives to help shape and run it, recruiting the people behind the offers through a neighbourhood platform they already used. Next to it stood a temporary bike-sharing station that needed no docking infrastructure at all, since it worked as a designated area inside the city's existing mobility app. The whole thing was set up and operating across roughly six weeks of one summer ([[Publications/6|Deliverable 6.1]]).

Neither route is the better one. They buy different things. A built station commits capital and leaves a permanent asset that is hard to reverse. A temporary set-up produces evidence, and a working relationship with the people who might use the permanent version, inside a single season and for very little money. The DREAMS review makes the same point about hubs generally, that a tactical approach lets them be prototyped and tested before anything is made permanent ([[Publications/3|Deliverable 2.2]]). The question to settle before delivery starts is which measures in your package you are confident enough to build outright, and which ones should be tried in a reversible form first while the capital is still uncommitted.

== Record it while it happens ==

Alongside measuring what an intervention achieved, DREAMS evaluates how it was implemented, looking at the decisions taken, the governance and stakeholder dynamics around them, the logistical and organisational problems that came up, and whether administrative delay played a part ([[Publications/6|Deliverable 6.1]]). That work is mostly interviews and conversation, and it is much easier while people still remember.

Keep a short dated record of each deviation and the decision taken in response, from the first day of delivery. It costs very little and it is what makes the next two steps possible. An indicator that comes back disappointing has two quite different explanations, that the measure was the wrong one or that it was never delivered as designed, and only the delivery record separates them. The same record is what lets [[Review and learn lessons|the final step]] pass on something another outskirt can actually use, which is rarely the measure itself and almost always the account of what it took to get it built.

<div class="dreams-handoff dreams-handoff--dive">
<div class="dreams-handoff__label">Go deeper</div>
Delivery is thinly covered in most planning guidance, so two sources are worth the detour. The Baltic Sea Region Competence Centre's module on [https://bsr-sump.eu/m4-small-scale-experiments/ small-scale experiments] argues for testing before investing and backs it with pilots from Helsinki, Aarhus, Groningen and Turku, a step-by-step model for planning one, and a short risk-assessment exercise you can run over your own first measures. For the contracting half of this step, the EU reference guide on [https://urban-mobility-observatory.transport.ec.europa.eu/document/download/3c614dd0-4138-4b96-bc06-dc4e09e4149f_en?filename=public_procurement_of_sump.pdf public procurement of sustainable urban mobility measures] walks through a procurement stage by stage, including life-cycle costing and how a specification can pull a market towards the outcome you want.
</div>
<div class="sump-sources">
<div class="sump-sources__title">Sources and further information</div>
<div class="sump-sources__item"><span class="sump-sources__ref">EU SUMP Guidelines, Second Edition</span> (Rupprecht Consult, 2019), Step 10, Manage implementation.</div>
<div class="sump-sources__item"><span class="sump-sources__ref">[[Publications/5|DREAMS Deliverable 5.1]]</span>: set-up of the living labs, including the Budapest service and station schedules and the Vienna flexible hub.</div>
<div class="sump-sources__item"><span class="sump-sources__ref">[[Publications/6|DREAMS Deliverable 6.1]]</span>: the living lab interventions and timelines, and the process evaluation approach used to study how they were implemented.</div>
<div class="sump-sources__item"><span class="sump-sources__ref">[[Publications/3|DREAMS Deliverable 2.2]]</span>: operator compliance, market volatility and the tactical approach to prototyping hubs before permanent implementation.</div>
<div class="sump-sources__item"><span class="sump-sources__ref">[[Living_Labs/3|Living lab Budapest, Rákosmente]]</span>: the lab's own account of the rollout and the shortened operating period.</div>
<div class="sump-sources__item"><span class="sump-sources__ref">[https://nachhaltig-mobil-planen.de/_SUMP/DE/Planung/SUMP-Prozess/4-Umsetzung-Monitoring/10-Umsetzung/umsetzung.html Umsetzung gewährleisten]</span>, German national SUMP portal, Bundesministerium für Verkehr.</div>
</div>{{SumpStep/bottom|step=10}}