Tag Archives: 911

Wedding Open Source to Government Service Delivery

One of the challenges I’m most interested in is how we can wed “open” systems to government hierarchies. In a lecture series I’ve developed for Health Canada I’ve developed a way of explaining how we do this already with our 911 service.

To begin, I like using 911 as an example because people are familiar and comfortable with it. More importantly, virtually everyone agrees that it is not only an essential piece of modern government service but also among the most effective.

What is interesting is that 911, unlike many government programs, relies on constant citizen input.  It is a system that has been architected to be participatory. Indeed it only works because it is participatory – without citizen input the system falls apart. Specifically, it aggregates, very effectively, the long-tail 0f knowledge within a community to deliver, with pin point accuracy, an essential service to the location it is needed at a time it is needed.

I’ve visualized in this slide below (explanation below the fold)

long tail public policy

Imagine the white curve represents all of the police, fire and ambulance interventions in a city. Many of the most critical interventions are ones the police force and ambulance service determine themselves (shaded blue). For example, the police are involved in an investigation that results in a big arrest, or the ambulance parks outside an Eagles reunion concert knowing that some of the boomers in attendance will be “over-served” and will suffer a heart attack.

However, while investigations and predictable events may account for some police/fire/ambulatory actions (and possibly those that receive the most press attention) the vast majority of arrests, fire fights and medical interventions result from plain old 911 calls made by ordinary citizens (shaded red). True, many of these are false alarms, or are resolved with minimal effort (a fire extinguisher deals with the problem, or minor amount of drugs are confiscated but no arrests made). But the sheer quantity of these calls means that while the average quality may be low, they still account for the bulk of successful (however defined) interventions. Viewed in this light 911 is a knowledge aggregator, collecting knowledge from citizens to determine where police cars, fire trucks and ambulances need to go.

Thus to find a system that leverages citizens knowledge and is architected for participation we don’t need to invent something new – there are existing systems, like 911, that we can learn from.

With this in mind, two important lessons about 911 leap out at me:

1) It is a self-interested system: While many 911 callers are concerned citizens calling about someone else I suspect the majority of calls – and the most accurate calls – are initiated by those directly or immediately impacted by a situation. People who have been robbed, are suffering from a heart attack, or who have a fire in their kitchen are highly incented to call 911. Consequently, the system leverages our self interest, although it also allows for good Samaritans to contribute as well.

2) It is narrowly focused in its construct: 911 doesn’t ask callers or permit callers to talk about the nature of justice, the history of fire, or the research evidence supporting a given medical condition. It seeks a very narrow set of data points: the nature of the problem and its location. This is helpful to both emergency response officials and citizens. It limits the quantity of data for the former and helps minimize the demands on the latter.

These, I believe, are the secret ingredients to citizen engagement of the future. A passive type of engagement that seeks specific, painless information/preferences/knoweldge from citizens to augment or redistribute services more effectively.

It isn’t sexy, but it works. Indeed we have 20 years of evidence showing us how well it works with regards to one of our most important services.

My first 911 call – lessons for open systems

So this Saturday morning, on my way downtown to conduct a negotiation workshop for several wonderful people in Vancouver’s environmental NGO community, my friend Rikia and I were stuck behind a white 16 cubic foot box van that began weaving very erratically (I mean, into oncoming traffic erratically).

After some initial hesitation I made my 911 call ever.

(As an aside, I think I’m a pretty lucky guy to have made it to the age of 31 before feeling like I was in a situation where I had to call 911 – and frankly while this situation was dangerous, I myself was never in danger)

During the call I was struck by how patient and restrained the operator was. Although he never sounded cavalier, nor did I pick up any sense of urgency – likely a tactic to ensure callers stay calm. In addition, I noticed how the operator never doubted the underlying veracity of my story.

This observation got me thinking about a post I wrote a while back about how 911 is a perfect example of how public services already use open source principles. Accepting this argument, my 911 experience actually affirmed some things  I’m sure many open source veterans already know.

Any open system (and many closed ones) rely on a community of people to provide it with important data (e.g. where eradic drivers are, or where critical bugs may exist in the code). Since people often come into the 911 community (or an open source project) with a problem or concern they are likely predisposed to be agitated. Consequently, I suspect that open systems that retain the most users are those that are predisposed to assuage them and keep them calm. Indeed this probably not only improves retention (increasing the likelihood a caller/bug register calls again) but likely also helps maintain the sanity of those helping them. So lesson one: a little patience is essential for long term success.

In addition, I mistook the road the truck was driving on not once but twice (talk about testing one’s patience!). However, if the operator was annoyed,  I didn’t know it. While it is important that 911 get accurate information a worse outcome would be for a call where the operator and the caller get into a dispute – if a user has a negative experience with 911 they may never call again – significantly diminishing the value of the system and increasing the risk to society. Obviously the stakes aren’t quite so high for an open source software project, but putting a premium on accuracy above all else probably isn’t wise either. While we want users to be accurate – a system that penalizes inaccuracy so heavily that they never return is probably not wise either. So lesson two – always lead by trusting, but of course, verify.