Getting the police to think like a startup
Thief-catching involves a lot of technology — but as an organization, the London Met isn’t very good at adopting new tech.
Back in 2013, I was a policeman in Hackney, London. As a bit of a nerd as well, in April, I got involved with a Hackathon organised by the Metropolitan Police.
It was an interesting challenge; I wasn’t much of a coder (and, frankly, I’m still not — although I do know my way around a programming language or two), and they don’t usually let me near any of the felt-tip pens. Nonetheless, I figured I could use what I know about the police, and about the methodologies of building user-first software, to contribute in my own way.
The Met is a great organisation, but it has a few challenges around technology. The key one, in my mind, is that they are spending a staggering amount of money for old tech — again and again — so I decided to demonstrate the concept of a rapidly iterating Minimum Viable Product to the management of the police.
One example where there is huge costs involved, is the Mobile Data Terminals (MDT) that are installed in police cars. Though various Freedom of Information requests and conversations with police officers at the hack day, it turned out that the hardware alone costs between £4,000 and £6,000 per unit. There are at least 700 vehicles in the Met that operate MDTs — that’s £2.8–4.2m worth of hardware installed in Met vehicles. Which, given what the MDTs actually do, is pretty outrageous.
Replacing these units with iPads would do some interesting things. At £370 per unit, measuring 700 iPads in millions of pounds becomes a silly-looking figure: It’s £0.26m. I don’t know how long a police car stays in service, but I’m willing to bet that the huge difference in cost would be noticeable in budgets very quickly.
There are several steps to cutting cost; Using commodity hardware instead of custom-made MDTs is an obvious first step, but there are also enormous savings to be had in relation to processes, especially in re-considering how software and systems is developed for the Met, for example
Prototype fast. Fail faster. Succeed earlier.
Since I’m a big fan of lean start-up methodologies, I decided that my demo for the Hack the Police wasn’t going to be a finished product (how could it be, in 48 hours worth of coding). The product itself was never meant to be complete — instead, it was a process demonstration of how to use design thinking and rapid iterations to build a testable prototype of a product.
The goal was to create a scenario that front-line officers are extremely familiar with: being on the street, needing to check details on a person or vehicle. The point was to do a demonstration of how you can gain valuable feedback and information from poice officers by developing a Minimum Viable Product (MVP). Think of it like a highly advanced and very visual wireframe, that gives the illusion of being a working product. As such, when you are looking for feedback and validation for an idea.
Why would you bother with a prototype?
To understand why prototyping is important, it’s useful to know how government procurement often works in situations like this.
What the Met would usually do is to spec a full MDT system. 18 months later, it is delivered. Then it gets deployed, the officers are trained, and everything is gravy. Except it’s 18 months and several million pounds later. Some organisations are willing to accept that sort of investment and risk; as a startup founder, however, it scares me: There’s no way I would even consider working in the dark for 18 months, and investing several million pounds into an important project.
So… How can you de-risk a project that is so large, and so core to front-line policing? What would a start-up do to get early product validation and a tight feedback loop to ensure that if you are running at full speed, at least you’re running in roughly the right direction?
Thinking Minimum Viable Product (MVP)
As a police officer, you sometimes have to check people’s details — to see whether they are wanted by police, for example. At present, the procedure is as follows: You use your radio, go on the support channel and hail an operator. You’re then put in a queue, which can sometimes be pretty long. Then you use the phonetic alphabet to read the person’s details (“Last Name Sierra Mike India Tango Hotel. First name Mike India Charlie Hotel Alpha Echo Lima Alpha, Female, date of birth 20 June 1988”). They look it up in a computer, and tell you the results.
In summary: You use a radio to talk to someone who types something into a computer, and then reads out what’s on the screen in front of them. In my mind, that’s like calling your sister, who is a nurse in a busy emergency medicine unit at a hospital, asking her to take time out of her day to Google something for you.
So, my MVP — the smallest possible slice of the Mobile Data Terminal project — is to replace the most common requests done over the radio with an app.
The basic idea is to find an answer to the following statement: “Yes, we do want to replace everything about the MDT. Simultaneously, we want to give you something that can be completed as quickly as possible. If I were to give you an app that does X, would you use it?”. If the answer is ‘yes’, then you go build it. If the answer is ‘no’, then you scrap the idea. If the answer is ‘yes, but how about you do Y and Z instead? That would make more sense to me as a front-line officer’, then you are really onto something: You will be building the right thing, but better than you would have without proper feedback.
My ‘app’ is a type of MVP — a prototype. The idea is to create a highly realistic mock-up of how an app would work, and talk to a series of police officers. I would talk them through a very visual and hands-on mock-up of how something could work.
Can I see the mockup?
I thought you’d never ask!
Launch the app, and admire the fantastic splash screen. With apologies to Simon Pegg:
Vehicle checks
Let’s take a closer look at ‘vehicle check’…
Now, after the photo has been taken, the app has gone to the server, and it has discovered that there’s something fishy about the car you just scanned. Instead of showing you any other details, it goes straight into ‘officer safety’ mode, and flags up the relevant details right away. In this case, it flags that this vehicle has certain warning codes associated with it, and should only be stopped with Trojan assistance (i.e. armed police) as a result.
One of the drivers have a red dot next to their name, signifying that there’s something odd going on with that person. Perhaps they have a driving ban, or maybe there is something else you need to know about them before stopping the vehicle. In this case, since the red dot is next to the only female on the list; if the driver is female, that should increase the risk assessment.
Person checks
Go back to the main menu and click ‘Person Check’. You’re now taken to a menu where you can choose what you want to scan — a passport, driving licence, or just manually enter details
The details came back… And should look familiar, because this is the same screen as you got via the other route.
Nothing about this prototype is rocket science, and obviously all of it is simulated. Building the connections to the Police National Computer etc is the tricky part, from a security and policy point of view — and, given that the PNC is an ancient piece of software running on scarily old servers — it is non-trivial to implement from a technical aspect, too.
What’s the benefit?
I demoed this simple prototype to a load of officers throughout the week-end, and was able to make a large number of adjustments as I was iterating through feedback from the officers.
One example: One of them said “Why can’t I check Crimint as well?” The beauty of using rapid prototyping is exactly moments like that. In my mock-up, I am able to add 5 lines of code, and I’ll have added a slider for Crimint.
Compare that with the risk of finding out at the end of a 18-month project, that an officer would like to be able to check Crimint. Adding it into a ‘finished’ product is a much larger task, with huge costs associated. The flipside is also true: What if you included an interface for checking a particular system, that no front-line officer would ever use? In that case, you’ll have spent time and money developing something nobody will ever use. In start-up world, that would be an unacceptable level of waste — and in police world, the same rules should apply.
Ultimately, the point is that building prototypes and putting it in front of end users as early as possible in the process helps refine the product development cycle.
