What Developers Need to Know
Understand the life cycle of the administration
Each organisation and each government institution has a very specific yearly cycle when they do budgets, decide what kind of process is going to happen and what kind of things have to be in place, etc. Just taking some time to understand how it works can make it so much easier to negotiate with them or to talk with them. Sometimes it helps you to understand what kind of specific offering they might want based on where they are in the cycle. And sometimes it will be a clear indicator whether they actually have money or not. So if you’re coming to them in the middle of the year, most likely they’re going to say, “Well, we already have our budget allocated. Come later.” The best time would be either the end of the financial year when they have to spend the rest of the budget that’s left over or, a little bit in advance, when you can start negotiating for the next cycle.
Don’t talk about functionalities right away
Instead of functionalities, start by talking about specific activities and the data that people want to get out of it. It’s very easy to get carried away with talking about very small, technical, little things — about how verification works or what kind of voting system you have, etc — and people on the other side will get overly excited and forget about why they actually need a civic tech tool. The risk for you as a developer is that you’re going to be blamed for not building the tool or generating the data that they actually wanted. So in order to be completely secure in what you’re doing, you need to understand whether they actually need this feature or not and why.
Clearly define your responsibilities
Responsibilities and the limitations of what you’re going to be providing are important to discuss. Oftentimes the client does not understand whether you have the capacity to provide, for example, advisory and communication services, or if you can do anything related to data analysis or presentation, etc. There might be assumptions made about capacity. So if you can, that’s great and you should write it down. In case you can not, it’s important to be very upfront about it, because otherwise there will be false expectations, leading to frustration on both sides. The city might say, “Oh, but nobody’s using the platform because there is no communication campaign happening,” and the provider will say, “Well, that’s not what we do. This tool doesn’t generate engagement by itself.” This sort of process is also very important for liability and legal reasons as well.
What Municipalities Need to Know
Understand the process first
As it is for developers, understanding the process comes first. You should also understand why you need technology. It sounds silly, but a lot of the time people are trying to implement digital participation because they think they need it, without really thinking about the bigger picture — the reason, the goal, etc. So before communicating with developers, sit down and understand why you want digital participation and what specific data you want to get. This is crucial because then it will help you understand or better communicate the different functionalities and requirements you have for the tool. It’s also good to have a specific person in the room grounding the conversation — reminding everyone to think about the bigger picture. Some municipalities go and present a digital participation solution without really knowing how the processes work and then it becomes one big mess. They choose something that just looks nice from a technical perspective but doesn’t necessarily fit the project.
Understand who you want to engage
This rationale here is essentially the same as it is for understanding the process, as it’s about knowing what kind of digital tool you need and whether you need the digital tool in the first place. Having this profile of who the end user is, or who the citizen is, is going to help when designing and setting up the platform. After all, it’s about engagement — actual engagement — and how it’s going to work on the ground.
Communicate what kind of tools you already use
This can help the developers really understand what the internal level of know-how is, and also what kind of things can be complemented by their tool. It can also help them create a better offer and describe how exactly their tool can interact with those tools. So before you start this process of interacting and collaborating with the developers, it’s very good to take a step back, look at the process, what you have, see what’s missing, define the requirements and only then go into it. Built into this is, again, that you don’t leap straight into talking about functionalities. You lay the groundwork and only then translate what’s needed into functionalities. As fun as it is to talk about every little feature, those are ultimately minor details and should be discussed at the end.
This article was produced in cooperation with Participation Factory. Participation Factory is a social enterprise that mainstreams participation and data-driven approaches into governance and process design. Our experts support local governments in designing participation driven processes and systems, building capacities of their team, and implementing digital participation tools and Civic Tech. To learn more, refer to our website or contact us at info@participationfactory.com.
