End-Product as an Inclusive Process
The process of preparing for the Public Policy Forum Ontario Digital Inclusion Summit presentation was actually quite challenging — from understanding inclusivity beyond accessible design and service standards to rolling it into a simple story that is inherently about fear of failure, especially in cross-domain collaborations. Sharon and I also didn’t want to repeat the word inclusion and its variations 57 times on a Saturday afternoon towards a roomful of people who have been sitting all day, so we decided to talk about our own failures from the perspective of an early-stage private company trying to build tools for civic good.
The Guelph Civic Accelerator (really a procurement experiment) was the first time Milieu was able to interface with practitioners in public sector urban planning. Prior to the Civic Accelerator, we had worked on the idea and design with residents and community leaders in Ottawa, but the opportunity to work with a municipality was a breakthrough for us, a small startup. Thinking back about this project, it might have been unwise to work with a municipal department at such an early stage of building this company. I will get into why at the end of this post.
Our team was developing a platform to makestatutory planning data easily accessible for residents to understand the decision-making process. At the same time, enabling city staff members to use resident-generated data to understand where they can improve their services.
We ran workshops,talked through mockups and selected data to be rendered on the platform. After that, we felt ready to build and launch a prototype to test and evaluate this project with local residents.
Problems soon emerged as we started the implementation phase. Everyone wanted the prototype to be perfect and compliant to every possible rule. The desire to launch a perfect prototype eventually became new requirements developed under unvalidated assumptions for the software and roadblocks that were not discovered during the design phase. In the end, despite the best efforts from both parties, the prototype never reached residents.
One example was the API (Application Programming Interface)that we built for piping data from the city’s database to Milieu. We had reached a mutual agreement during the design phase to have city build their end of the API and we would provide an endpoint for them to push the data programmatically — it would eliminate the need for staff members to input the same data multiple times into different platforms or learn to use a new content management system. However,when we completed our API endpoint, their end wasn’t built. We had to spend additional months re-engaging with city staff members and designing an alternative approach for data to be rendered on our interface. At this point, the resources ran dry (Milieu was on a fixed-price contract with the city), and we had to pull the plug on this project.
The intended end-product never reached the real world.
I started looking into why we have failed. I was puzzled — until I realized that the entire project was based on assumptions. The original challenge was framed around “making it easier for residents to give feedback on urban planning decision-making process”. Naturally both Milieu and planning staff members were eager to make things perfect for our intended end-users — the residents. While this is generally true for the staff members representing the public sector, we misinterpreted the definition of an “end-user”.
We realized that the end-user should not only recipient of an end-product. An end-user should be an active participant of the entire process of product design. This means that end-users are not solely the residents — ,they are also public sector planner, the IT department, the person maintaining the service and on and on. on. Rather than designing a perfect end-product for one end-user, we should design a process that is inclusive enough for as many end-users to understand the evolution of the product as possible (within reason), especially in a Public Private Partnership. The current model of PPP should really be upgraded into a Public Private People Partnership. This process not only puts people in the centre of developing a product, but also allows more active knowlege-sharing among different sectors.(and I didn’t come up with this notion. It is widely explored by researchers world-wide)
Although this procurement experiment ended bitterly, it was in fact a failure so epic that both the City of Guelph and Milieu gained tremendous insights. We now have a direction on how to move forward and serve our “end-users” better using emerging technology and digital tools. We now know that we need to design a process that is inclusive and can help our customers succeed without having to rely on “tech support” and special configurations. We learned to treat our design and development process as an inclusive product, so that people that we work with can have the opportunity to understand how their tools are being designed and built.
This experience of failure deserves more merits.
Going back to why I think Milieu was unwise jumping into this project as a young company: we were operating under a tight budget and high expectations. It nearly killed us. But the focus here shouldn’t be on failure itself, but on how our culture refuses to recognize the importance of questioning and challenging the status quo, and at the same time anticipate unexpected results. These results can be good (success) and can also be bad (failure).
In the case of the story above, failure is linked to the fact that we were unable to deliver a product as stated in the original challenge Many perceived this event as Milieu’s inability to deliver without knowing that the original intent of this project was an experiment to figure out if startups and municipal departments could co-create better digital services to serve the residents.
However, if you want to know why we did not simply supply an “engagement platform”, a simple google search would tell you the reason. We proposed an API-first approach during the Civic Accelerator, because we learned from the planners reasons why residents were not able to access information conveniently at the first place. Ultimately, we wanted planners to stop manually transporting data from one content management system to another for greater efficiency. We took a risk hoping to unclog this data pipeline, and it simply did not work the way we have anticipated.
Was it really a failure?
I asked a question about their fear in cross-sector collaborative work.
One response from Sli.do that I really wanted to hit on is “Fear: Looking Stupid.”
“Looking stupid” can mean a lot of things. Most people in decision-making roles are previlaged enough to access higher education and have years of experiences in solving high-complexity problems within a given domain.
Being open to possibilities and having moments where you think deeply about what you don’t already know is not “Stupid”. Our individual knowledge is limited in comparison to the collective knowledge.
Watch ODIS day-2 presentations here
