8 min read

This blog post is the second of a three-part series. See the exciting Prelude for a brief introduction to this series of blog posts. The blog series adopt a socio-technical approach. Particularly, it considers people and technology on an equal footing when it comes to assessing their influence (or ‘agency’) on planning processes.

Part 1 explores the recursive nature of digital participatory platforms (DPPs) / SaaS (Software as a Service) / Civic Tech for community engagement in urban planning. In a nutshell, it argues that humans and machines must work together to produce wise(r) decisions in planning for a better future, even in the current tech- and policy-driven push toward data-driven decisions. Going forward, the differences and overlaps between evidence-based planning and data-driven planning need to become more explicit. The stakes are high, namely: the capacity to co-produce inclusive, healthy and resilient places that are not just future-proof but also guarantee everyone’s well-being and capacity to thrive.

This is Part 2. It focuses on what the lifecycle of digital participatory platforms might look like from the perspective of client organisations – which are typically local planning authorities.

Exploratory findings

The diagram below encapsulates emerging findings from the data I collected as part of the PhD. You can find the full description on pages 293-298 of the thesis. The diagram is on page 295 (reproduced below). The data consists of 50+ interviews with urban planning professionals, + just under 30 survey responses, +13 interviews with software providers. Finding out about the procurement of Civic Tech software at client organisations was not the main goal of the research. Nonetheless, the findings generated interesting, emerging insight on the topic. The diagram is therefore exploratory and could benefit from your comments to add greater value to the planning community at large – including LPA planners, consultants, start-ups, elected officials and community groups.

I start with a general overview of the diagram, and then briefly discuss each component in sequence.

0. The overview

Mini glossary:

• DPP = ‘Digital Participatory Platforms’ = Civic Tech = SaaS for community engagement = any other term that denotes ‘e-Participation’ and related technologies. See the Prelude for more details, as well as this typology of digital participatory platforms.
• PP = Public Participation

Planning typically starts with a plan (comprehensive/strategic, metropolitan, local, neighbourhood, or other) or a development project –> the orange box at the top.

Planning also ends at the end of a planning process, or project development –> the orange boxes at the bottom.

Here, we take the perspective of a SaaS for community engagement at a planning organisation. The lifecycle of a DPP / online community engagement project might also come to an end at the end of a single plan or project. Alternatively, a client organisation might choose to change the way it goes about engaging urban residents (‘Modify PP approach’).

In the middle, a plan/project will determine the specific needs for community engagement. Accordingly, the planning needs will influence the ‘Selection process’ and the way the platform is used (‘DPP use’).

Interestingly, a lot does happen during the use of a platform is used. This is where a lot of exciting and challenging work takes place.

1. The plan/project

The plan/project kickstarts the whole SaaS lifecycle process, from a planning perspective.

Typically, the Local Planning Authority will decide what happens based on existing needs in the community. This may be a comprehensive plan or masterplan that is being renewed, or a large regeneration / neighbourhood renewal project. The specific needs for community engagement might be determined by existing guiding principles for public participation at the local authority (see for example the Engagement Strategic Framework at the City of Boulder, Colorado, and at the practical handbook to citizen participation at the City of Grenoble in France – in French). Likewise, the capacity to engage the community will be determined by in-house resources and available funds for outsourcing the community engagement work. Last but not least, the will to engage the public typically stems from a political ask or commitment to build/restore trust, transparency, collaboration and partnership with residents. Some elected officials can be particularly active in promoting, if not in overseeing, the overall engagement process.

Mike Saunders, CEO at Commonplace, provides some perennial common-sense advice about how to start conversations that matter, early on in the planning process:

The way to begin a plan-making ‘conversation’ is the same as any other conversation: establish who we are talking to; discuss our respective interests; and create a rapport – before tackling topics that require deeper thought, reflection or debate.

Foreword to the ‘Engaging for the future’ report (Commonplace, January 2021)

2. PP Design and DPP design

The design of the SaaS / DPP platform will be determined by the type and scope of the plan / project. A specific project will call for particular choices in terms of public participation strategy, within which the DPP will be used.

In the case of participatory budgeting, and other technology-reliant projects and processes, the very nature of the planning endeavour will be inseparable from the technology itself. What can be done as a project will depend on the technology, and vice-versa.

Staff at local authorities might perform proactive market investigation and get in touch directly with tech vendors to find about costs, product specifications / participatory functionalities, and so on. Pioneer client adopters of pioneering start-up technologies will evolve together as a brand new market and field of community engagement is created. One can cite the relationship between the city of Rennes and the Cap Collectif platform, or the relationship between London boroughs and the Commonplace platform, when the respective start-ups were just ‘starting up’ and developing their services in accordance with expressed needs. These relationships have proven foundational in first creating, and later in (re-) shaping the technology, methodology and markets for web-based community engagement in urban planning.

In fact, DPP design can happen continuously as part of ‘Continuous DPP upgrades’. These might happen live during the course of engagement projects and processes.

3. The selection process

‘Selection process’ can be a more general umbrella term for procurement.

Platform design and procurement are interrelated, for example in terms of product specifications, as described above. Procurement leads are often community engagement officers and other project leaders within planning, communications and/or community engagement units at the client organisation. That is, it is they who will work closely with procurement staff.

Four options stand out. First, the client organisation procures a whole ‘public participation package’. A versatile consultancy or multi-skilled tech vendor is commissioned to perform the full engagement works. Some software providers, such as Repérage Urbain in France and Spacescape in Sweden, truly excel at providing all-round community engagement services alongside fit-for-purpose spatial analysis. These consultancies can combine both in-person methods with online engagement.

Alternatively, DPPs can be procured directly through single-source procurement, OR through competitive procurement, where tech vendors will bid for tender. The main selection criteria are typically: 1) the range of functionalities on the platform including participatory functionalities for end-users, and back-end data management, export and visualisation and workflow integration; and 2) the cost of the platform. Licenses can be project based, annual, or bi-annual. Finally, a client organisation might develop its own bespoke platform with in-house ICT/GIS/other relevant staff, or through its usual IT provider.

4. DPP use

This is where the action really takes place!

Planning process and workflows

The platform is used by the outsourced consultancy and/or project leads at the client organisation. The data collected from urban residents can be used within a single project, or across different projects. The City of Helsinki, for example, has pooled the collected data for staff to use across planning projects as needed.

As the DPP gets used and input is collected through public consultations, this can lead to intra- and cross-departmental collaboration among staff as well as collaboration between staff and residents –> In the case of participatory budgeting, this can also stimulate collaborate collaboration among residents -especially between different project holders, but also between project holders and budget delegates in US-based participatory budgeting, where some of the work that would be performed by council staff in Europe is actually delegated to volunteers in US cities. As introduced in Part 1 of the blog series about the potential for recursiveness in participatory planning, the very nature and purpose of technology is to (re-)shape workflows. In turn, evolving workflows will also (re-)shape the technology based on both pre-existing and emerging needs. Workflow and technological innovation occur simultaneously, and sometimes even recursively.

Finally, elected officials may also actively collaborate with city staff. This was the case in a range of projects, from the marketplace redesign in Hexham, UK, to multi-site regeneration across the Toulouse metropolitan region (‘Dessine-moi Toulouse’).

Continuous DPP upgrades

As the platform gets used, continuous platform upgrades might broaden the range of functionalities or help improve workflow integration. Product upgrades typically arise out of client requests. Particularly when technologies are new or in Beta version, there can some back-and-forth between client organisations and software providers. In the case of the open-source software Decidim initially developed at the City of Barcelona, a bespoke international support and software development community now exists that improves the platform on a continuous basis (MetaDecidim).

Evaluation

Not everyone does it, but an evaluation phases enables to objectively assess whether a SaaS platform and overall community engagement process was effective / useful / valuable, or not. Evaluation can be based on citizen feedback about the process itself, or from city staff. This can be based on qualitative insight, or quantitative data, such as participation metrics and website analytics, such as the number of participants, number of submitted comments and suggestions, number of votes for specific project ideas, etc.

5. Decision-making

In turn, the evaluation of the effectiveness of the platform and/or overall process will inform planning decisions, including the choice of whether to end the lifecycle of the DPP. Decisions will likely lead to some ‘Change’ or other.

6a. Change

One decision outcome might be to procure another platform or request product upgrades / add-ons to the tech vendor. Change might also take the form of modifying the design of the overall approach to public participation.

6b. Next plan or project phase

A planning process may feature several stages, such as metropolitan plans, or the iterative development and prioritisation of specific development proposals. For instance, the Stickyworld software (now Confers) Hexham marketplace redesign project allowed residents to identify current problems with the public space, suggest proposals, and provide feedback on finalised proposals. At the Grenoble metropolitan agency, the Carticipe-Debatomap software was first used to identify issues across the region, and then secondly to suggest solutions to the identified challenges.

Toward continuous becomings

The overall lifecycle of SaaS for community engagement ties this blog post back to Part 1 about the recursive quality of planning practice, identity and processes.

If one adopts a socio-technical perspective, one might reckon that SaaS technologies for community engagement do not necessarily reflect about themselves or even dream of recursive procurement. And yet, perhaps such is their nature after all: to outlive themselves beyond their iteration in particular projects or planning processes. As they are coded into the fabric of planning, their pervasive agency is both far-reaching yet difficult to assess and measure objectively – precisely because they are difficult to disentangle from the social, political and policy contexts in which they are deployed.

This begs, or prompts, the question of where they truly begin and end. Do they ever really die – and if so, which parts of them do, and which parts continue to evolve? As data gets used across several planning projects to inform better/wiser decisions and create a more balanced evidence base, planning processes and technology mutually shape each other recursively over time. Community engagement is not an one-off event. It is an ongoing dialogue and conversation which builds and must be nurtured over time beyond the duration of discrete projects and plans, all the more so as planning is increasingly ‘projectified’ and fragmented.

As the PlanTech and PropTech conversations continue to gain traction in both policy and industry, client organisations and software providers will continue to need each other to help make planning more effective together with, rather than just for, the public.

The next frontier for community engagement to plan for a better future, as my research indicates, lies in phygital, recursive and co-productive engagement. This will be the topic of a bespoke future post.

Part 3 in this blog series will now turn to the view from software providers.