Our doctrine and approach on technology and innovation – the very very short version

2017 version – 2021 version coming soon

Somebody asked us about our doctrine and approach on tech and innovation earlier this year, and we wrote this down as a ‘very very short answer’.

There’s a lot of people doing ‘tech4dev’, ‘m4dev’ and so on out there, but often it’s a bit of a black box what they’ve done, and how they’ve done it, especially for FCAS – a  black box that clients wouldn’t settle for in ‘ordinary’ IT systems procurement.

Whereas we think that working in FCAS contexts needs more transparency about how technology works, and more assurance that it does, than the average context.

So we’ve put this out as a first instalment about how www.sssams.org, www.hrisrss.org, www.nsams.org and more have been developed; our code is on github; and we will be writing more about the specifics in the coming weeks.

Our approach in wider context: moving fast, pragmatic and knowledgeable approach to FCAS context

Our approach brings together common elements of:

  • Agile Development, as commonly understood and applied in IT
  • The ‘Doing Development Differently’ approach put forward by ODI, Professor Matt Andrews (HKS) and others
  • Our own FCAS-specific approach to technology and innovation, with a proven and award-winning track record in South Sudan, Somalia, Sierra Leone, Nigeria and beyond, and across a suite of tools covering HR, Payroll, Attendance, Decentralised Financial Management, Operational funding of service delivery units, and, in each case, providing near real-time reporting
  • The Digital for Development Principles – www.digitalprinciples.org

How we develop

  • Working with users to set out clear requirements statement, not imposing off-the-shelf supposed ‘best international practice’
  • IT supports the process, not vice versa; IT works as far as possible with the grain of existing templates and approaches
  • Fast prototyping and piloting, not laborious design-then-build
  • Fast scale-up
  • Delivering tools in beta and improving in service and with users
  • Integrating development, training and support:  training is supporting users with real tasks; using remote support/’ghost’ applications

What we develop – operational characteristics

  • Real-time information is more useful, and provides more accountability, than retrospective reporting
  • A common taxonomy across modules for identifying subnational levels, service delivery units (clinics, schools etc), workers and service users, geographical information, types of income and expenditure etc
  • All materials are designed to be capable of a choice of multiple languages of user interface

What we develop – technical characteristics

  • Open source: no seat licences – once the code is developed, the recipient owns it and can develop it as they choose; no paid-for-software requirements (database packages etc)
  • Own device: no bespoke hardware requirements, users typically use their own devices
  • Resilience and multiple channels: systems that support inputs from, and reports out to users, by most or all of plain text SMS, form downloadable to smartphone, offline entry/online upload, web interface
  • Building on a set of modules that are already in successful national use in FCAS locations
  • Clean interfaces, not a sprawling mass: modules can output to a file format that can feed to another module within our suite of systems, or to other systems (legacy or new)
  • Integrating paper and digital: the most suitable Information Technology at local level is often a triplicate form; counter-signatures and stamps are often there for a reason
  • Transparency by default: all data above the level of individual workers or users should be public by default, and shown on the open web