Before the Singapore Police Force (SPF) upgraded their search screening platform, its investigation officers had to go through a long process just to look up information like vehicle plate numbers. Information was stored on different databases and a single search could take up to 20 minutes to retrieve results.

Today, SPF’s officers have JARVIS, a much speedier screening platform that works like Google search. A single press of a key turns up the smallest amount of information even as the system keeps working to generate relevant results – all within a few minutes. Making multiple searches is fast and easy.

JARVIS was built in collaboration with Open Government Products (OGP), a division of the Government Technology Agency. Initially, the SPF wanted a solution that used artificial intelligence (AI), says Mr Nikhil Choudhary, a software engineer at OGP.

But when the OGP team dug deeper, they found that the main problem was the screening system’s extremely slow speed.

“AI has a lot of buy-in and hype,” says Nikhil. “But a lot of AI hasn’t been figured out, and there are many other easier things we can do with more impact that would solve the problem.”

After spending 18 months to understand the problem and do the planning, the team built JARVIS rapidly, with the tech solution engineered in just four months, says technical lead Alwyn Tan, who built an early prototype for a faster search tool.

Changing minds

Understanding the real problem to be solved is an important part of creating tech products for agencies’ use.

While OGP works on specific products, Nikhil says the aim is to change the overall view of IT from being an operational function to a strategic one. This means asking the more fundamental “Why?” questions before the “What?” or “How?” questions.

Other OGP projects developed in-house came about because the team observed that many different agencies faced similar problems, such as struggling with paper forms. This led OGP to create FormSG, a simple form-builder that any officer can use, as well as the link shortener Go.gov.sg and website builder Isomer.

Alwyn says: “We are recognising that the same problems are repeated at multiple places and wanted to create solutions that allow agencies to ‘self-service’ tech solutions for themselves.”

Use simpler language

During sharing sessions, Nikhil likes to share reminders of how to work on tech projects: Start small, reiterate. Fail fast, fail often. Prototype.

He prefers using this simpler language to comparisons of “agile vs waterfall”, methods of working in IT and buzzwords that can be misused by those who want to do the traditional waterfall method but call it agile. “Jargon gets in the way,” says Nikhil.

He adds: “It’s because we’ve been able to do that – fail fast, fail often; prototype; start small; test hypotheses – that we have been able to build good products, not because we had a grand vision or a grand strategy.”

Be comfortable with failure

For those who are hesitant to try new ways of creating tech, Nikhil highlights that there is room in the Public Service to allow for the fast failure necessary to create innovative solutions. One is the use of language that tempers expectations, such as “pilot”, “trials” and “phase one”.

There are also institutional structures. The Ministry of Finance and the Smart Nation and Digital Government Office have set up funds that encourage public officers to experiment, with bigger budgets for longer-term projects.

Support for experimentation that comes “straight from the top” matters too. Leaders need to be accepting of this mindset of experimentation. JARVIS, for example, had the green light from SPF’s senior management, which helped to make the new tech happen.

Tips for collaborating with OGP

Come with a problem statement, not a solution

Using the analogy of visiting the doctor, Nikhil says: “You don’t go to a doctor and say, ‘I need a bypass surgery’. The doctor will be the one to do the diagnosis: identify what’s wrong and what’s the solution.”

Public officers’ experience of working with external IT vendors, having to give specific requirements and passing down orders has had an influence, Nikhil says. “We are not so comfortable with empowering our in-house engineers to make the right decisions,” he observes.

OGP is working to change that mindset – having officers shift from giving orders to working together to solve problems. “A big part of what we do is to scope out problems, figure out what the use case is and deliver value,” adds Nikhil.

How to identify the problem

Expect the OGP team to ask a lot of questions.

Nikhil says: “We try not to be ‘order-takers’ so we really try to push and ask the more fundamental questions.”

One question you might hear is “What are you trying to do?”

Software engineer Alwyn, who used to work in banking, says the question is a crucial one that his training instructors then drummed into him, as it reveals motivations that drive intent.

Other questions to guide you in identifying a problem include:

• Do you really need a solution for this?
• What is your motivation for doing this?

Reframe the problem statements you come with

Now that you know to go to IT engineers with problems, not solutions, be sure you’re bringing the right problems: what the end user’s needs are, not your agency’s or your boss’s ideas.

“If our end goal is to make citizens’ lives better, we need to explicitly acknowledge the things that are making their lives worse,” wrote OGP Director Li Hongyi in an article for Civil Service College’s Ethos journal. “Beware of bureaucratic goals masquerading as problem statements.” (see sidebox for examples)

Nikhil’s tips are to avoid being prescriptive (“We want to use X or Y”) or including requirements from the start (“We need at least one X solution”), and examine what the user’s problem or need is.