Improving strategic planning and monitoring with HPC.tools

Humanitarian InSight is a portal providing access to data from around the Humanitarian Programme Cycle. Read an intro to how this works. One of the key tools in the HPC.tools suite that Humanitarian InSight relies upon for its data is the ‘Response Planning and Monitoring’ module, which allows the humanitarian community to work together both during the strategic planning process that takes place every year, and the subsequent periodic monitoring of the key indicators that were agreed as part of that plan.

What the tool does

The Response Planning and Monitoring module (or RPM for short) is the place in which all the different elements of the strategic framework come together. Usually in such a framework, at the top there are some high-level strategic objectives, and then individual response sectors agree on sectoral objectives that are aligned with those strategic objectives, and finally on activities that are needed to achieve those objectives. At each level of the framework, we identify ‘caseloads’ – such as the number of people in need, or the number of people targeted for assistance – as well as key indicators that will allow us to assess our response. We can also estimate the financial requirements of framework elements, from individual activities, to entire sectors or the plan as a whole.

What makes this so difficult is that there is no standard way of implementing the framework, and because each humanitarian response addresses quite different needs in quite different contexts (is it a sudden-onset natural disaster or a long-standing conflict? What role does the national government play? How is the humanitarian plan aligned with longer-term development objectives? …and so on), in-country coordinators may make very different decisions.

So at the very core of the RPM tool is an enormous degree of flexibility, that allows the entire framework, and all the work processes around it, to be completely customised – but retaining some common elements and ideas that allow us to bring the data together in a coherent fashion in sites like Humanitarian InSight.

How it works – some technical details

The entire user interface of the tool is driven by a template. This template is a JSON object that stores all the information about the different elements within a framework, what they are called and how they related to one another, and that is entirely user configurable. The template is constructed on top of just a few core concepts.

• The first is that each plan will have one or more ‘governing entities’ correspond to real-world coordination entities that are responsible for defining and monitoring the framework. Often these are called ‘clusters’, but they could be called anything.
• The second is that each plan will have one or more ‘plan entities’, that could be called things like ‘Strategic Objective’ or ‘Sector Activity’ (but again can be called anything) and that relate to one another in some kind of hierarchy.
• The third is that each entity within a plan can have any number of different ‘attachments’ which represent things like indicators, or caseloads, or costs, or even things like contact details.

Given that relational data – connecting data together – is at the heart of the HPC, the tool uses the JSON templates as an intermediary between ‘fundamental’ elements (such as what an ‘indicator’ is), and actual plan elements (such as a strategic objectives or actual indicator values defined by end users), all of which are stored in a typical relational database (in our case, we use PostGreSQL). That way, we get the flexibility of a ‘No-SQL’ approach without losing the easily-queried structured connections that our data needs. And users are never faced with an unpleasant surprise when their innovative approach to improving the management of humanitarian response in their country is met with ‘Sorry, but the tool doesn’t support this’…

Further improving the tool

Tools such as RPM, and other tools in the HPC.tools suite, are all developed using what we call an ‘agile’ approach. This means that instead of going out, asking everyone what they need, developing something that corresponds to what people said they needed, and then walking away for 10 years until a new tool is required (which is what we used to do), now we quickly develop prototype tools that meet some of those needs, and then help people start using them. As we work with the humanitarian community on the front line, we understand much better what it is they actually need than we ever could just asking them up front, and we iteratively improve the tool – sometimes pushing out some new features just a few days after they were requested. This approach is ‘baked in’ – the iteration just keeps going over the years, so that as the users’ needs change (which happens a lot in the humanitarian community, where strategic approaches are constantly in flux) the tools change with them.

The price we pay for this is that sometimes, the tools don’t yet do everything when we first launch, and some things work better than others. But having an evolving tool with a few kinks that need to be ironed out is better than having a perfectly-functioning tool without any problems but that all too often doesn’t allow users to do what they want.

The tool in practice

RPM is one of the core tools that enable the humanitarian programme cycle – because the strategic framework that is managed within it then forms the basis for the project registration and financial tracking processes supported by other tools within the HPC.tools suite. It is currently being rolled out across all the major humanitarian responses. If you see planning and monitoring data appearing on Humanitarian Insight for any crisis, that’s because the data is being collected and managed in RPM!