Transitioning from OPS to the HPC.

tools Projects Module

for 2019 HRP project registration
Guidance Note for OCHA field offices and partners, updated 7 September 2018
This guidance outlines the major changes in functionality and workflow procedures when using the
new HPC.tools Projects Module for 2019. It complements a more detailed technical manual,
available separately, which provides exact instructions on how to navigate and use the new tool.

Contents
Support ........................................................................................................................................... 1
NO CHANGE
1. Accessing the Projects Module ................................................................................ 2
NEW
2. Customising project registration for context-specific needs .............................................. 2
NO CHANGE
3. Linking projects to plan frameworks ......................................................................... 2
NO CHANGE
4. Registering multi-organization projects ..................................................................... 3
NO CHANGE
5. Registering multi-year projects ................................................................................. 3
NEW
6. Registering and approving projects across multiple clusters or sectors ............................ 3
SOME CHANGE
7. Registering and approving refugee projects ........................................................... 4
SOME CHANGE
8. Cash transfer programming ................................................................................... 5

Support
As 2019 is the first year in which the Projects Module is in widespread use (after field piloting in
Libya and Chad in 2018), there is full hands-on support available at all times.

Training
OCHA field offices will be fully trained by the HPC.tools team at HQ on how to use the tool. In turn,
the OCHA field offices will provide training opportunities for partners in the field, which will be
closely supported by the HPC.tools team.

Ongoing support
For all technical support questions, e.g. how to log in, how to register a missing organization,
how to navigate the tool and search for projects, how to approve or reject a project, etc., a
dedicated helpdesk is available as part of the HPC.tools team at ocha-hpc@un.org. OCHA field
office IMUs can also assist wherever they have the opportunity.
For all substantive issues related to the planning process, e.g. how to answer the questions on
the project registration form (including any context-specific questions), how to decide which
projects to approve, how to assess the overall cluster and inter-cluster requirements, etc., support
is provided as follows:

 First by the OCHA field office, through the inter-cluster coordinator and HPC focal point;
 Then by the planning focal point at OCHA HQ.
Although projects registered in the Projects Module are subsequently tracked by FTS throughout
the year, FTS is not directly involved in the project registration process itself and does not provide
any direct support to field users for this registration process. However, the HQ planning focal point
does liaise behind the scenes with both the HPC.tools team and with FTS to inform the support
they provide.
 NO CHANGE
1. Accessing the Projects Module
While the process is exactly the same as it was in the old OPS in 2018, the URL for the new
Projects Module is http://projects.hpc.tools. Users who try to access the old link will be directed to
the new URL. As before, all users are required to sign into the new Projects Module using their
Humanitarian.ID. This means that all previous OPS users (as well as anyone else with an H.ID)
will already have access to the new system. New users without an H.ID will need to create one first
before accessing the Projects Module.
As last year, when first signing in users will be asked to choose their organisation from a list. If their
organisation is not on the list, they complete a form to request its addition. This form must be
approved at HQ and the organisation added to the global list before the user can enter the system
to add their projects.

 TIPS
 Cluster coordinators (and their designated counterparts such as cluster IMOs) with the right
to approve or reject projects must be given the correct access level. As in previous years,
this means that you must provide your APMB focal point with an up-to-date list of cluster
coordinators and counterparts.
 However, as the same list is required for cluster coordinators to be able to add and edit
their cluster frameworks in the HPC.tools RPM module (which should happen before
project registration), you are strongly advised to provide this list to APMB at the very
beginning of your HRP process.

2. Customising project registration for context-specific needs NEW

Unlike the old OPS system, in the new Projects Module, each country is able to customise the
project sheet template differently according to context-specific needs. These should be
collectively agreed upon in the inter-cluster coordination group. The basic template is as light as
possible, including only a few standard questions on needs, activities and the use of cash. To this,
any number of additional fields can be added (including open-ended text fields, drop-down
selections, checkboxes etc.) depending on requirements.

 TIPS
 Every additional question increases our partners’ registration burden, and so should be
justified carefully with a consideration of what the data from each question will be used for –
in which products, for what analyses, and in support of what decisions. If there is no clear
rationale for adding a question, and especially when it requires some effort for partners to
answer, then reconsider.
 This year, the configuration of additional questions has to be done at HQ. Therefore, you
must inform your APMB focal point of what questions to add at least two weeks in
advance of the beginning of your project registration period.

NO CHANGE
3. Linking projects to plan frameworks
For all projects intending to be accepted as part of an HRP, an integral part of the project
registration process from now on (and already offered in the old OPS system in 2018) is that, in
addition to selecting which cluster/sector the project is in, project owners select which
framework indicators, activities and objectives the project will contribute to.
As the HRP’s strategic framework is a vital tool for monitoring and accountability, OCHA and its
cluster partners should be able to track which projects, of which organizations and in which
geographical areas, are contributing to which elements of this framework. This allows coordinators
to be able to identify and mitigate gaps at the planning stage, and subsequently improve
continuous monitoring, gap analysis and adjustment during the implementation stage.

 TIPS
 The framework is registered in the HPC.tools RPM module, by the OCHA plan lead (HPC
focal point or IMO) and the cluster coordinators. Many country offices are already using this
tool in 2018. Additional support is being provided for those countries who are not yet using
it. In 2019, the strategic frameworks for all HRPs will be available on RPM.
 To be able to link all projects to the framework, ideally the framework should be fully
defined and finalised, with all activities, indicators and targets set, before project registration
begins. However, experience from our pilots in Libya and Chad last year has shown that
this timeline may not work in all cases. Therefore, countries should aim to have as much
as possible of the framework finalised before project registration, and then work with
partners to help project owners update their already-created projects as necessary, once
the final elements of the framework are in place.

NO CHANGE
4. Registering multi-organization projects
As in the old OPS, the HPC.tools Projects Module can be used to register projects that are
shared across several organizations. Note that this does not apply for a project that is financed
by one organization as the project owner and fundraiser, but carried out by downstream
implementing partners who are sub-contracted by the primary organization. It applies to co-owned
projects where the organizations share top-level responsibility.
If more than one organization is selected, then (as with old OPS), the project’s total budget/project
cost needs to divided between the organizations. This division is mandatory: without knowing
how much of the project’s requirements are attributable to each organization, it would be
impossible to calculate and report on total requirements per organization, or subsequently on
percentage covered per organization.

 TIP
 This division can be based either on absolute value or percentages. The tool will initially
propose an equal split, but this can (and should) be adjusted to the correct amounts or
proportions.

NO CHANGE
5. Registering multi-year projects
In 2019, the Projects Module does not yet support the registration of multi-year projects. This
feature is being developed and will be available the following year.
This means that the approach taken to projects as part of multi-year plans this year will be the
same as last year: all projects should be registered as single-year projects, and their budgets
should only cover the programmes that are proposed to be delivered during that year.

 TIP
 For multi-year projects, the project start date and end date recorded in the Projects Module
can reflect the full duration across multiple years, but the budget or project cost should
only be for the single year.

6. Registering and approving projects across multiple clusters or sectors NEW

In 2019, the Projects Module now supports the registration of projects across multiple
clusters and sectors. Therefore, a project that is carrying out activities in Health and in Food
Security should select both clusters from the list, and subsequently link the project to objectives
from both clusters.
If two (or more) clusters are selected, then the project will need the approval of both cluster
coordinators to be accepted as part of the plan. If there is a disagreement between the
coordinators, the project owner will need to revise the project before being able to proceed. Also,
the project’s total budget/project cost needs to divided between the clusters. This division is
mandatory: without knowing how much of the project’s requirements are attributable to each
cluster, it would be impossible to calculate and report on total requirements per cluster, or
subsequently on percentage covered per cluster.

 TIPS
 If a project has distinct well-defined activities in each of several clusters, then all of the
relevant clusters should be selected from the list. If, however, the project is a genuinely
‘multisectoral’ project that cannot be divided – such as a multi-purpose cash project – then
it should it be assigned to whichever cluster or coordination entity the HCT has created or
authorised to review and oversee such projects.
 In certain cases, a cluster may cover activities in more than one ‘global sector’ – for
example, a particular response may have a “Health and Nutrition” cluster covering activities
in both the global health sector and the global nutrition sector1. If a cluster like this is
selected, then the project’s budget will need to be divided between the associated global
sectors.
 The division of the budget, if required, can be based either on absolute value or
percentages. The tool will initially propose an equal split, but this can (and should) be
adjusted to the correct amounts or proportions. The individual amounts can be anything
from 0 to 100% of the total project budget, but taken together they must add up to 100%.
 The Projects Module does not support overlapping budgets, where the entire project budget
contributes simultaneously to the requirements of several clusters. For such projects, the
budget can either be assigned entirely to one of the clusters, or divided between them.

SOME CHANGE
7. Registering and approving refugee projects
In 2019, the procedure for registering refugee projects in the Projects Module has changed slightly
from the old OPS. But two key points remain unchanged: first, the tool does not support mixed-
population projects. All such projects should therefore be split into two projects, or attributed
wholly to Refugee Response2; second, any projects that are part of the Refugee Response,
regardless of sector(s) of intervention, are approved exclusively by UNHCR and not by the
Cluster coordinators.
In all field contexts with Refugee Response coordination, this appears as a separate option in the
cluster/sector list, and this should be selected in addition to any specific project sectors. This
means that:

 For a single-sector refugee project, e.g. one that delivers food assistance to refugees, a user
should select both Refugee Response and Food Security from the list. Only UNHCR will
approve the project, but for sectoral analysis purposes (including in the Food Security chapter
of the HRP), the project’s caseloads can be shown together with the food security-related
caseloads managed by the Food Security cluster.

1
Field clusters are activated locally based on context, needs and mandates, and may differ from one response to the next. On the other
hand, global sectors describe the type and nature of the work and are based on a standard global list.
2
In practice, projects with mixed populations that cannot be split into separate projects and whose targeted caseloads are at least 50%
refugees should be attributed to the Refugee Response.
 For a multisector refugee project, where requirements are not divisible by sector, a user
should select only Refugee Response from the list. Only UNHCR will approve the project.

 TIP
 If a refugee project has distinct well-defined activities in each of several sectors, then all of
the relevant sectors should be selected from the list in addition to Refugee Response. To
enable sectoral analysis and financial tracking, the project’s budget will need to be divided
between the associated global sectors. However, even in this case only UNHCR will
approve the project.

SOME CHANGE
8. Cash transfer programming
Under guidelines discussed with the Cash working groups and the Global Clusters, in 2019 the
Projects Module, as part of every project registration (regardless of cluster or sector), will request
information on the following:

 Whether the project involves cash-transfer programming; and if so,

 How much of the project (to the nearest 10%) is CTP; and
 Whether the CTP is restricted (including vouchers), unrestricted cash, or a combination of
the two.
A question on conditionality is no longer required, as this was assessed to be of less use to cluster
and inter-cluster-level coordinators and strategic-level decision-makers at the global level.
However, countries can still add a custom question on conditionality if they wish, and conditionality
will remain part of 3W tracking.

 TIPS
 A single-sector cash project, or one covering multiple well-defined sectors (where the
budget is divisible between them), should select the correct cluster/sector(s) from the list in
addition to answering the CTP-related questions. These projects will be approved by the
relevant cluster coordinator.
 Cash projects targeting refugees should follow the guidelines in the previous section, in
addition to answering the CTP-related questions.
 For multipurpose cash projects, users should select whichever cluster, sector or entity
has been agreed in-country by all concerned to have approval oversight for such projects.
In some contexts, this may be a particular designated cluster or set of clusters; in others it
may be a ‘Cash working group’ or similar entity which will appear on the list. In either case,
the CTP-related questions still need to be answered.