9 min read

This blog post is the third and last in a short series about the lifecycle of SaaS for community engagement / digital participatory platforms in urban planning. The insight is exploratory and is based on emerging findings from my PhD thesis.

The Prelude presents the series. Part 1 delves into the recursive quality of participatory planning practice and the role technology can play to support it. Part 2 explores the findings proper, looking at the lifecycle of digital participatory platforms from the perspective of client / sponsor organisations. To provide examples of the type of technology being investigated here, this post provides a typology with examples from the thesis.

This blog post is somewhat similar to Part 2. The primary difference is that it takes the view of software providers, which can be tech vendors or versatile planning consultancies. These differences revolve around Civic Tech activism, proactivity, customer support, and licensing mode (Open Source vs proprietary). The conclusions also differ from Part 2. The exploratory diagram below is based on interviews with thirteen different software providers, as well as survey and interview responses from 80+ planning professionals about 60 use-cases.

Note: This is an exploratory lifecycle diagram. The findings are emerging. Its value is heuristic and meant to be improved based on your feedback to further benefit the wider community. As explained in the Prelude, I adopt a socio-technical approach that puts technology and people on an equal footing as regards their influence on planning processes and practices.

An exploratory lifecycle of SaaS for community engagement

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

The start and the end point(s)

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 software providers regarding the path that a SaaS for community engagement follows at a client organisation. The lifecycle of a DPP / online community engagement project might come to an end at the end of a single plan or project. Alternatively, a client organisation might change the way it engages with urban residents –> ‘Client modifies PP approach’.

While a specific engagement project might end, the use of the platform might continue across different projects, for example if the license/contract is annual/bi-annual rather than project-based. Also, a client might stop using the DPP, but the data it collected might still be used across future projects at the organisation even after the platform subscription has come to an end.

It can also be the case that engagement portals for local authorities are migrated from one provider to another… I have seen this happen at several local authorities during the course of the PhD, which was also reflected in some of the reported findings in thesis.

The core of the activity

In the middle of the diagram, a plan/project will determine the specific needs for community engagement. Interestingly, three factors come to the fore: 1) the planning needs in terms of community engagement and platform functionalities; 2) the actual functionalities available on a platform; and 3) existing relationships between tech vendors and individual staff at client organisations, especially via proactive market investigation on the part of organisational staff, and marketing and activism / participatory planning ethos on the part of Civic Tech start-ups. In several instances, the participatory planning ethos of both client organisations and software providers, as made explicit in public participation charters and corporate mission statements, respectively, aligned quite nicely to enable long-term collaboration.

Naturally, the functionalities on the platform 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 for both organisational staff and customer success representatives at the Civic Tech companies.

1. The plan/project

The plan/project kickstarts the whole SaaS lifecycle process. It is typically initiated by a Local Planning Authority / council / metropolitan agency, even where the tool is adopted by a planning consultancy on behalf of a local authority. Likewise, a developer may be leading on the project as ‘kickstarter’ or trigger, but sooner or later there will be constraints arising from statutory planning and local development constraints associated with local authorities.

Typically, the Local Planning Authority will decide what happens based on existing needs in the community.

Although the plan/project is the main source of upstream influence, clients’ awareness of what is possible to achieve in terms of online public participation may sometimes influence significant design components of the planning process. This is particularly the case of

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, where the respective start-ups were just ‘starting up’ and developing their services in accordance with the pre-existing and emerging needs of client organisations. These relationships have proven foundational in first creating, and later in (re-) shaping the technology, methodology(-ies) 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, the diagram in Part 2 also shows that a client organisation might develop its own bespoke platform with in-house ICT/GIS/other relevant staff, or through its usual IT provider. The high level of customisation and ownership expected by some local authorities is perhaps something to consider for SaaS software in their marketing and customer success strategies. Module- or block-based, generalist engagement platforms might be most versatile and customisable in terms of appearance and functionalities.

4. DPP use

This is where all 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). Some proprietary software vendors have also built an international community of good practice among their clients, through such media as online webinars and practical workshops at leading planning and placemaking conferences.

At critical stages in the planning process, it goes without saying that technical customer support should be highly responsive in the occasional (and possibly disastrous) event of technical shortcomings. Low responsiveness may lead to significant frustration for staff at client organisations, with potential knock-down effects of undermining trust and transparency between local authorities and urban residents.

Evaluation ↑↓

Process and product evaluations at client organisations are closely connected with continuous DPP upgrades, as based on experiences from adopting them in planning processes and workflows.

Not every client does it, but an evaluation phase enables to objectively assess whether a SaaS platform and overall community engagement process was effective / useful / valuable. 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.

Respondents at client organisations and software providers both shared that the next frontier for workflow integration and leveraging the best value of DPPs lies less in fancy applications such as augmented reality (AR) or virtual reality (VR), or even 3D city models, but much more in better data visualisaiton, reporting, workflow integration, data privacy, collaboration capabilities, and project-based back-end segmentation for different staff involved in different projects. Therefore, emerging evaluations from the interviews and survey responses largely pointed to improvements in back-end functionalities rather than front-end, participatory functionalities for urban residents / consultees.

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 the client modifying the approach to public participation.

Planning forward – Engaging for a better future

Among other key industry reports, the Engaging for the Future report by Commonplace (January 2021) provides important insight and recommendations for the planning system to move forward. Although the report is UK-based, the ‘participation deficit’ that can be observed in local communities across the globe must be heeded if we are to plan forward to net zero – and even beyond, toward a regenerative planning system. There is no ‘planning back’ – to paraphrase the Building Forward report by the Bennett Institute of Public Policy in Cambridge.

As the digitisation of planning systems is under way globally, and self-organisation (i.e. agile, responsive and proactive) planning emerges as a new paradigm for more fit-for-purpose planning policies, local digital innovation and embeddedness will likely be of primordial importance. One can witness a dual dynamic featuring the growing importance of ‘locality’ and local innovation on the one hand, and the ever-greater internationalisation of SaaS for community engagement in urban planning on the other, with notable exceptions (e.g. Commonplace, PlaceBuilder, PlaceChangers, Cap Collectif, that remain primarily national in scope).

A recommended read is the report by Filer (2019) ‘Thinking about GovTech’ about digital innovation hubs and GovTech ecosystems. Although aimed at policymakers, it provides ample high-level food for thought about how engagement portals could nest themselves even further in a progressive delivery of public value and services, not least in making public procurement more accessible to new SaaS start-ups on the block.

Beyond innovative phygital/blended modes to engagement, it seems the future of participation in planning could also lie in deploying elaborate mutually-supportive ecologies and ecosystems for the co-production of all the interlocking policies that underpin the resilience and overall quality of places and the spaces between them. As the unfolding climate crisis reveals, there are many things beyond planning that shape planning processes and practices in rather powerful, tangible ways.

[Pinned / featured image credit: Photo by Compare Fibre on Unsplash]