FINNISH RED CROSS INTERNATIONAL OPERATIONS AND PROGRAMMES · 3 (34) appendix 1 finnish red cross international operations and programmes and the objectives for the project information

1 (34)

APPENDIX 1

FINNISH RED CROSS INTERNATIONAL OPERATIONS AND PROGRAMMES AND THE OBJECTIVES FOR THE PROJECT INFORMATION MANAGEMENT SYSTEM

No. 2014-031329

14 January 2015

FINNISH RED CROSS INTERNATIONAL OPERATIONS AND PROGRAMMES

The Finnish Red Cross (FRC) is the largest Finnish civic organisation providing humanitarian aid and conducting

development cooperation. Every year, the FRC carries out some 300 international projects with a total value of

approx. EUR 35 million. The nature of the projects varies from short-term disaster response operations to long-

term development cooperation projects. The FRC operates through the worldwide network of the International

Federation of Red Cross and Red Crescent Societies (IFRC) and its member national Red Cross and Red Crescent

societies operating in each country of operation as well as the International Committee of the Red Cross.

Further information is available on the FRC website at www.redcross.fi.

FRC International Operations and Programmes have 49 employees based in Finland and some 30 long-term

project-based workers (delegates) in various countries of operation. The number of project-based workers and

programme countries changes each year. On average, the FRC sends 200 aid personnel per year abroad to

participate in international operations and programmes.

Background and objectives

The work of the FRC International Operations and Programmes is project-based. The basic tools of project

management are already in use, such as the project cycle, operating instructions and document templates.

However, the expanding volume of assistance operations and the growing number of projects and donors have

changed the nature of the work and created a need for developing the electronic operating environment for

project management in order to maintain its high quality.

The project information management system is expected to support a more efficient use of resources, to

increase interaction between the FRC Headquarters, field-based staff and partners, and to ensure the openness

and transparency of operations to the beneficiaries, donors and stakeholders. The aim is to enhance and

support decision-making and the steering of international activities and improve quality in general through

improved information management and automated data analysis.

The specific challenges facing the existing way of managing the projects carried out by FRC International

Operations and Programmes include the financing base of projects becoming more complex, the reporting

requirements becoming more donor-specific, the growing number of disaster response projects, the shortening

of response times, and the growing need to produce and obtain up-to-date information on the implementation

of projects, financial management, procurement activities and HR management.

End-users of the project information management system

The individuals using the system in Finland include:

Programme coordinators and officers acting as the person in charge of development cooperation

projects and disaster response operations in their area of responsibility. The areas of responsibility of

2 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

programme officers have been defined geographically (e.g. Eastern Africa, Southern Africa, Latin

America).

Finance, programme and HR assistants responsible for the administrative support tasks of projects.

Advisers who contribute to projects through their thematic or stakeholder-specific know-how, for

example in planning, monitoring and evaluation tasks.

The FRC International Operations and Programmes division management team, whose members are

responsible for project management or the related support services. The team is also responsible for

decision-making concerning programme and operational entities, the overall development of

operations and ensuring the accuracy of donor reporting.

Support function (financial management, HR management, procurement and logistics) coordinators and

planners in charge of project-specific support functions.

The individuals using the system outside Finland include:

Delegates, i.e. project-based workers sent abroad by International Operations and Programmes, tasked

with helping partners in the country of operation to implement projects and operations and maintain

the high quality of activities.

Regional advisors (e.g. health and disaster preparedness advisors), who support aid projects and

operations related to their own field of expertise in certain geographical areas covering many countries.

Regional finance and administration delegates responsible for the financial management tasks of

projects and operations carried out in their region of responsibility, including budgeting, monitoring of

costs and financial reports, quality assurance, and the provision of development support to country-

specific partners.

Regional representatives responsible for the coordination of FRC activities, cooperation with

stakeholders, HR management tasks of delegates and the financial management tasks concerning

regional functions within their region of responsibility.

Finnish Red Cross project cycle

The project cycle of the Finnish Red Cross is described below in order to provide an overall picture of project

management at the FRC. Activities are based on individual projects or operations, or programmes or operative

entities comprising multiple projects of operations. A project comprises a predefined number of activities that

share the same objectives, implementation schedule, budget and monitoring indicators. A programme

comprises more than one project, which share the same programme objectives, implementation schedule,

budget and monitoring indicators. Disaster response operations can be operative entities comprising several

sub-projects involving aid to individuals, managing service units (e.g. hospitals, clinics, camps) and providing

logistics or financial support.

The FRC project cycle comprises four phases:

3 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

1. Preparatory phase 2. Planning and formulation phase 3. Implementation and monitoring phase 4. Exit and evaluation phase

The preparatory phase is for identifying the need for a project. The identification is based on the international

assistance policy, regional strategy and regional action plan of the FRC, and informed by the policies and

strategy of the donor. In disaster or conflict situations, the FRC will receive a direct request via the IFRC or the

ICRC network. The purpose of the preparatory phase is to ensure that the project idea is aligned with the FRC’s

international assistance policies and the requirements of our international partner, as well as its feasibility and

eligibility for funding. Based on a project proposal, the director of the division will decide whether to move the

idea to the planning and formulation phase and give permission to launch the planning of the project. The

permission to launch planning will authorise the use of FRC resources in order to draw up a project plan.

The planning and formulation phase is for drawing up an actual project plan, including a budget and a funding

application, on the basis of a needs assessment. The needs assessment of the beneficiaries of a project or

disaster response operation is conducted in cooperation with the partner in the country of operation. In disaster

or conflict situations, the needs assessment can be conducted by the IFRC or ICRC on behalf of the FRC. Support

services such as HR management, financial management, procurement and logistics, will play their part in

putting together a plan for a project or operation. The purpose of the planning and formulation phase is to

prepare the planning documentation in such a way that it will meet both the FRC’s quality criteria and the

donor’s requirements. The head of the unit will ensure that the quality criteria are met, and approve the final

project documentation to be presented to the donor as part of the funding application signed by the director.

This phase is completed when the back donor either rejects or accepts the application for a project or

operation.

The implementation and monitoring phase is the longest phase in the project timeline, comprising the largest

part of the project or operation-specific work, both in Finland and in the country of operation. The

implementation phase begins with the launch of the project/operation, at which time, both in Finland and in the

country of operation, an operative work plan and a monitoring system will be created for the project, and the

necessary human resources will be recruited on the basis of the project plan. During the launch phase, the FRC

and the partner implementing the project will agree on the project management practices, a common project

control system and reporting; these need to be in line with the donor’s requirements. The partners

implementing the project will report to the FRC on the progress and costs of the implementation at 1–3 month

intervals. One part of the implementation phase is the on-site monitoring of the progress of the implementation

through monitoring missions and mid-term evaluations. Based on the monitoring results, the head of the unit

will decide whether to terminate the implementation phase at the end of the funding period or to propose

making a new funding application for the project.

The exit and evaluation phase takes place at the end of a project. Closing a project always requires drawing up

a separate exit plan. A similar exit plan is also drawn up for disaster response operations. The exit phase of a

4 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

project involves certain administrative measures, such as ending local contracts, transferring project property,

closing down project accounts, drawing up final reports, and checking and archiving documents. It also includes

defining measures for ensuring the sustainability of key functions after they are no longer supported by the

project (sustainability planning). Projects or operations nearing their end will be evaluated either by the FRC or

the IFRC. Evaluations can be conducted before or after the project has been closed (final evaluations, ex-post

evaluations). The results of the evaluations will be used in the planning of new, similar projects and operations.

The project cycle is supported by various support-function processes, such as those used for handling

procurement, the recruitment of delegates and field financial report management.

Systems in use

The Finnish Red Cross is using Windows Microsoft Office 2010 and Windows 7. The systems in use, with which

the project information management system must be interoperable (system integration), include (at least):

MS Dynamics NAV – a financial management solution that will be deployed at the FRC in 2016.

Integrating financial management with project information management is crucial; it will cover

budgeting and enable project and programme-specific cost monitoring.

REST – a system built to meet the HR management needs of FRC International Operations and

Programmes. The system must enable information searches based, for example, on the duration of

employment contracts.

Interface descriptions are provided at the end of this document.

At present, project management documentation is saved on a common drive (T-drive) in accordance with a

standard folder structure. From the T-drive, the documents will be transferred, where relevant, (automatically)

to the new project information management system.

General specifications for the project information management system

Ease of use and learning the system. Due to the nature of the work, system users will change frequently,

and new users will emerge in large numbers in relation to the total number of users. For many users,

the time that they use the system will be short on account of the limited duration of their work

assignment. It is not always possible to provide in-depth training to users because some of the

assignments are launched on a tight schedule.

Using the system in online and offline modes. The project sites are often located in areas where there is

no access to the Internet, or the connection is weak and slow. The users should be able to read and edit

information in offline mode, and synchronise the edited information once the system is reconnected to

the Internet.

The system’s primary language option is English. The FRC is also interested in Finnish and Swedish-

language versions.

5 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

The system will primarily be used on computers, but for future reference, the FRC is also interested in

the usability of the system on mobile devices (tablets, smartphones).

The system includes the option of defining different roles and rights of users (read only, edit,

administrator, etc.) in terms of access to project information. The programme officer, as the person

responsible for the project, will define the users’ roles and rights for each project.

Functionality specifications by key areas

Management of basic project management information.

Support to workflows. Each user has their own dashboard view of the projects in which they play a role.

The user is able to follow the events, tasks and schedules of projects via the dashboard.

The system includes an electronic approval function, for example, for the approval of various project

phases, financial reports and procurement requests in accordance with the internal guidelines of the

FRC.

The possibility to download, search, edit and categorise information and documents easily, for example

according to the project title, code, country, project type and time, and a free-text search field.

The project cycle, documents and reports can be modified in accordance with the project type and the

requirements of the stakeholders. For example, the operating practices for disaster response operations

and development cooperation projects vary in terms of timeframes and functions. There are also

differences in the requirements and operating practices of national partners and donors.

A decision-making register, in which approvals and decisions can be listed for the entire duration of a

project (e.g. dates, persons, documents and comments).

A calendar function in which the progress of a project can be monitored, including scheduled project

functions, training sessions, monitoring missions and report due dates.

Creating and editing documents, version control, document management.

Combining narrative and financial reports in a predefined manner based on project, programme,

function or donor. A single project may have several donors, or a single donor is funding individual

functions of several projects.

Combining individual projects or operations into programmes and operation entities with a single donor

and a common reporting schedule for dealing with both the donor and the partner societies.

6 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

Interfaces

This section describes the required interfaces of the project information management system in phases 1 and 2.

The interfaces are described by their data content only; the technical implementation of the interfaces is left

open. The system should provide interfaces containing the data described here as part of the implementation

project. The other systems will likewise provide data via interfaces such as the ones described here.

The data content descriptions are based on the foreseen needs for data transfers between systems. They are

included here to provide an understanding of the scope and complexity of the integrations. These descriptions

should be considered indicative, not actual definitions. The data transfer does not need to be real-time; e.g.

overnight transfer is sufficient.

The following diagram gives an overview of the data flows between systems:

Project Information

Management System

AccountingDelegate Reserve

DatabaseDelegate contract

dates

Project basic dataProject hierarchy

Chart of AccountsCost Centers

General LedgerOpening balances

Delegate Reserve Database to project information management system

The Delegate Reserve Database contains information regarding FRC’s delegates in reserve and on missions. The

most relevant information for the project information management system is the contract periods for

delegates.

The following data should be transferred from Delegate Reserve Database to the project information

management system. The Delegate Reserve Database will provide an interface with agreed technology. This

interface is included in phase 1.

Note: a single delegate project number may have more than one contract.

Field Description Example

Contract_id unique internal REST id

Project number

Delegate project number. Key for linking with data in project

information management system. 9939

First name Delegate's first name Maija

Surname Delegate's surname Meikäläinen

Contract start date Start date of contract 1.1.2013

Contract end date End date of contract - may be updated 16.4.2014

7 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

Accounting to project information management system

The accounting system contains financial information regarding FRC’s operations and programs, including

structural data such as cost centers and chart of accounts, and transaction data such as the general ledger and

opening balances.

The following data should be transferred from the accounting system to project information management

system. The accounting system will provide an interface with agreed technology. These interfaces are included

in phase 2.

Chart of Accounts:

Cost Centers:

Field Description Examples

Account number Numerical code 3100

Account name name Donations from public

Account type 1 Profit&Loss / Balance Sheet Profit&Loss

Account type 2 income / cost / asset / liability Income

Account type 3 type of cost / income DRF funding


Cost center code numerical code 214

Cost center name name Southern Africa

Owner Id internal person number

Owner Name responsible person's name Matti Meikäläinen

8 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

General Ledger:

General ledger data is transferred on transaction row level

Opening balances:

Opening balances are transferred only for balance sheet accounts, and only items where project code is defined

(not null).

Project information management system to Accounting

The project information management system will be the master system for project related basic data in the FRC

International Operations and Programmes. These will be transferred to the accounting system.


Period accounting period 012013

Voucher Class numerical voucher class code 9

Voucher Number voucher number 1004100

Account Number account number from chart of accounts 4150

EUR sum Amount in EUR 45,32

Cost Center cost center code 213

Project project code 8050

Donor main donor of the project ECHO

Budget Code budget / activity code of transaction 1.3.4

Booking method based on voucher class Travel bills

Project type humanitarian aid / development cooperation KAT

Channel Implementation channel, e.g. IFRC, ICRC… Bilateral

Partner Reporting Period

period partner is reporting. Can be different

from voucher period. Q2

Year Voucher period 2013

Pcs quantity 1

Description description of the transaction Taxi from x to y

Currency Currency code USD

Sum Amount in currency 55,7436

Voucher Date Date of the transaction 2.10.2013

Created On Creation date of the transaction 3.11.2013

Originating System e.g. travel bills, payroll, accounts payable… M2


Account Number account number from chart of accounts 1730

Project project code 7929

Year year 2013

Opening Balance opening balance of the account-project-year combination in EUR 100512,26

9 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

The following data should be transferred from the project information management system to the accounting

system. The project information management system shall provide an interface with agreed technology. These

interfaces are included in phase 2.

Project basic data:

Project hierarchy:


Project code Project information management system project code 8203

Project name name

Integrated Community Health and

Disaster Preparedness

Project class classification, e.g. delegate / program / etc Program

Type1 development cooperation / humanitarian aid KYT

Type2Code internal code 9

Type2 text description of project type Community Development

Subtype code internal code 110

Subtype text description of project subtype Disaster preparedness & prevention

Channel Bilateral / IFRC / IRCR Bilateral

Donor Main donor of the project UM KYT

Default Cost Center code of default cost center 214

Country code ISO standard country code ZW


SubProject code Project information management system project code (key) 9939

SubProject name name Maija Meikäläinen

Parent code

Project information management system

project code of parent project 8203

Parent name name of parent project

Integrated Community Health

and Disaster Preparedness

10 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

Detailed functionality specifications by project cycle phase (preliminary listing)

ID Group Requirement Document/Entity

Entity name

Priority

Reasoning/Comment

1. Functional Requirements: Development cooperation

1.1 Dev

Preparatory programming phase

The system shall store the information on identified project opportunities and tag them to e.g. country, sector or donor level.

Entity Project opportunity

2 "Idea bank"

1.2 Dev

The system shall enable creating a preparatory phase entity from a project opportunity or from a blank template.

Entity 1 "Draft project, pre-project, project skeleton"

1.3 Dev

The system shall enable document management related to project opportunities (creation from template, template management, uploading, copying, moving, editing, etc.) for preparatory phase documents such as work plan, planning of planning budget, concept note, ToR for assessment travel, delegate planning tool (if not built-in table in the system), summary of needs assessment, preliminary project plan, plan of action, risk & security analysis, letter of intent, etc.

Document 1

1.4 Dev

The system shall require approval for internal concept paper; however, the system shall not prevent proceeding to next cycle phase even if there is no approval.

Document 1 Enables following pipeline of projects under development per region and total volume. To grow volume planning pipeline also needs to grow; if not a sign to mgmt to allocate more resources & put more effort into identifying new project opportunities. This stage may require funding resources.

11 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

1.5 Dev

The system shall enable associating persons/users to preparatory phase entity as members. The system shall propose users from different user groups to ensure that all relevant parties are involved and notify the user when s/he has been associated to a project.

1

1.6 Dev

The system shall enable persons/users associated to initial assessment entity to edit information and to receive notifications when information has been edited by another member (e.g. concept paper has been approved).

1

1.7 Dev

The system shall enable formulating a preliminary project organization for a preparatory phase entity. This is to clarify the roles of the members of the project group and estimate resources needed such as staff member time.

1

1.8 Dev

The system shall require a set of criteria to be met / "ticked-off" by the preparatory programming responsible person before proceeding to requesting approval for project planning (suunnittelulupa). The criteria can include (i) project is based on FRC strategy, incl. regional strategy, (ii) it is based on FRC partner strategy, involvement and interest, (iii MoU and partnership agreement in place, (iv) realistic funding prospects exist.

1.9 Dev

The system shall require approval for project planning (suunnittelulupa), when the required criteria are ticked and the planning phase work plan and budget and estimate for total co-funding needs from FRC are attached.

1 Approved project formulation request entitles for using the resources for planning (funding from DRF/Kara).

1.10 Dev

The system shall create a project to track planning phase costs. This project will be linked to actual project if it proceeds to implementation phase. Other requirements for Project key data,

1 One project per donor, created annually? TBD

12 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

see section 6.

1.11 Dev EU

The system shall have a risk register (built-in table in the system) to allow user to register risks in a structured way. Risks can be tagged with different metadata fields and linked to documents.

1 Risk categories: project/operation related, country/partner related, strategic risks

1.12 Dev

The system shall store the 1st phase application for EU funded projects (concept note and possibly the log frame).

Document 1

1.13 Dev

The system shall require approval (external and internal) for the letter of intent and/or preliminary project plan.

Document 1

2.1 Dev

Planning and formulation phase

The system shall enable document management (creation from template, template management, uploading, copying, moving, editing, etc.) for planning phase documents such as project plan, budget, log frame, monitoring and evaluation plan, exit plan, delegate planning tool, project material plan, visibility plan, donor application, contracts, internal pledge note, etc.

Document/Entity

Log frame 1 Budget needs to be saved in an easily reportable format that enables them to transferred and managed. If a partner template is not available, IFRC template will be promoted and used.

2.2 Dev

The system shall have a project data/document/task checklist (configurable per project type, e.g. CBHFA, DP) to show which are the relevant tasks or documents at this phase. User will be able to see open tasks for his/her project/s. Tasks are user role specific and may relate to administration, quality assurance, etc.

Entity Checklist 1 See "Planning and QA Path CBP - principles and steps" or "Rapid checklist for successful project planning" as an example for (programme officer, advisor specific) tasks at planning phase.

2.3 Dev

The system shall have a task list for field planning & assessment and enable storing the relevant documentation.

1

2.4 Dev

The system shall have a task list for appraisal that is done at the HQ and enable storing the relevant documentation.

1

2.5 Dev

The system shall require review/approval for appraisal done at the HQ. Appraisal is both technical and qualitative and the criteria that needs to be met varies by project type, but always includes

1 Minimum appraisal criteria can vary from project to project not all criteria apply to all projects and the system should allow

13 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

e.g. project level risk assessment. ticking away irrelevant criteria.

2.6 Dev

The system shall store the application for funding. Document 1

2.7 Dev

The system shall require approval for application/project plan before it can be sent to donor (hakulupa/hakemuksen lähettämislupa).

Document 1

2.8 Dev

The system shall store the funding decision (yes/no) as well as the justifications and other relevant donor communications.

Document 1 Learnings related to applying for funding needs to be gathered in a single place. See 3.39 for learning portal/site.

2.9 Dev

The system shall require approval for internal decision document (päätösasiakirja) on the usage of disaster relief fund before an implementation phase project can be opened in the system (toteutuslupa). Internal decision document contains the information on funding amounts (external and internal).

Entity Internal Pledge Note

1 Internal decision document data can be used e.g. in liquidity management and DRF calculations. TBD: can some of the data come directly from budget?

2.10 Dev

The system shall create a project to track implementation phase information. Requirements for Project key data see section 3/Dimensions & Other structures.

1

2.11 Dev

The system shall create email notifications when a project is created in the system.

2 Notifications to accountants responsible for opening projects in other systems (Intime/NAV, e-Office, M2)

3.1 Dev

Implementation and monitoring phase

The system shall have a project data/document/task checklist (configurable per project type, e.g. delegate project, CBHFA, DP, etc.) to show which are the relevant tasks or documents at this phase. User will be able to see open tasks for his/her project/s. Tasks are user role specific and may relate to administration,

1 E.g. "Delegate deployment preparation process" (list of briefing needs, list of equipment needed, host NS invitation received, etc.), "

14 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

quality assurance, etc.

3.2 Dev

The system shall store the projects' kick-off meeting (aloituskokous) template. Kick-off is done both at the HQ (=administrative kick-off) and on the field (=operation implementation plan).

Entity 1 Kick-off meeting also mentioned in the chapter 4. A common tool for programmes, finance, and HR at the HQ.

3.3 Dev

The system shall have a built in "operational plan" template which defines key project milestones & deadlines and estimates resources required (time/missions) from HQ staff (desk, finance advisers)

The system shall inform about approaching deadlines and give red flags if deadline passed.

3.4 Dev

The system shall enable review/approval by the management that the kick-off has been carried out and operational plan completed.

1

3.5 Dev

The system shall have a place to store the baseline study. Document 1

3.6 Dev

The system shall have a built-in table "Indicator Tracking Table" to record the results of project's baseline study. ITT shall be built in a way that enables searching and analysing results e.g. per region.

Entity Indicator Tracking Table

1 In the future, partner (e.g. Kenyan Red Cross) may be able to access this part of the system.

3.7 Dev

The system shall have a place to store the mid-term review. Document 1

3.8 Dev

The system shall store the recommendations from the mid-term review into a database where they can be retrieved and reported per project/partner/etc. Other sources of recommendations include audits, travel reports, etc.

Entity Recommendations

1

3.9 Dev

The system shall have a built-in table for project's high level budget (field, delegate, FRC HQ, admin, total). Detailed budget

1

15 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

will be stored as an Excel.

3.10 Dev

The system shall enable monitoring the project plan and acting on deviations.

1 Includes also e.g. communications & visibility plans.

3.11 Dev

The system shall have a voucher check report for project's financial monitoring (internal audit) including data for following expenditure categories: 1) missing vouchers, 2) unjustifiable personnel costs, 3) costs unrelated to project, 4) other unjustifiable costs, 5) insufficient documentation.

1 Internal audit is done by i) project delegate, regularly or ii) by HQ staff/RFAD in case needed

3.12 Dev

The system shall have a place to store the bank receipt related to payment order, after which the payment status will be "completed".

3.12 Dev

The system shall allow linking projects to a larger "grant" management unit shall register tasks and alerts and decisions given for the grant.

4.1 Dev

Closing, exit and evaluation phase

The system shall have a project data/document/task checklist (configurable per project type or donor, e.g. delegate project, Dipecho project) to show which are the relevant tasks or documents at this phase. Tasks are user role specific and may relate to administration, finance, quality assurance, etc.

Entity Checklist 1 E.g. (i) Delegate employment termination process (end of mission report received, exit survey completed, debriefing done, field financial reports received, equipment returned, etc.). (ii) Dipecho project closing checklist (see example in separate document). (iii) Closing of the delegation task list (Annex 10E in FRC's Project Manual). (iv) Closure of field finance operations (from Finance and administration manual for FRC field operations).

16 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

4.2 Dev

The system shall have a place to store the end line study. Document 1

4.3 Dev

The system shall have a built-in table "Indicator Tracking Table" to record the results of project's end line study.

Entity Indicator Tracking Table

1 In the future, partner (e.g. Kenyan Red Cross) may be able to access this part of the system.

4.4 Dev

The system shall have a place to store the final evaluation.

4.5 Dev

The system shall have a recommendations database to store recommendations from final evaluation. Recommendations can be reported by partner, country, etc.


1 Sources of recommendations: travel reports, audits, evaluations.

4.6 Dev

The system shall store the project's hand-over agreement. Agreement covers the handing over of project's results or pending activities as well as project's assets and is linked to sustainability strategy and exit plan done at the planning phase.

Document 1

4.7 Dev

The system shall have a milestone for periodic audits or other audits.

Audit consists of number of documents that shall be stored in a single place connected to the project.

4.8 Dev

The system shall store audit recommendations, learnings, findings and the implementation plan for recommendations into a database where they can be retrieved and reported per project/partner/donor/etc.


1

4.9 Dev

The system shall have a place to store the project's final/annual report.

Document 1 For document metadata, see 3.18.

4.10 Dev

The system shall store the donor's feedback and approval of final/annual report.

Document 1

4.11 Dev

The system shall require authorization for (preliminary) closure, based on the approved final report.

1

17 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

4.12 Dev

The system shall store all the relevant closing phase documentation, based on the configurable checklist per project/donor.

1

4.13 Dev

The system shall store the information on reconciled field finances.

1 See 4.3 and 4.4 for finance processes.

4.14 Dev

The system shall require authorization for project's final closure. 1

2. Functional Requirements: Disaster response

2.1 Hum

Preparatory, Planning and Formulation phase

The system shall have a RSS feed functionality where an administrator can set up a number of RSS feeds to be listed on the system.

2 E.g. feeds from the IFRC or sites like "Hurricane watch".

2.2 Hum

The system shall enable recording crisis/disasters as entities per type and country/region. Does not necessarily lead to action on FRC part.

Entity Disaster/Crisis

1 Equal to "idea bank" in 1.1 Dev

2.3 Hum

The system shall enable proposal for FRC action including justifications (criteria for proposal).

E.g. extent of disaster (affected number, number of dead), immediate needs, FRC's partnership and history in the country, funding possibilities, delegate present or not.

2.4 Hum

The system shall log the decision on whether an action was taken or not regarding certain crisis/disaster (suunnittelulupa).

1 History on decision making per country.

2.5 Hum

The system shall store the negotiations/communication with donor (MFA, ECHO).

Document ( Email)

2 Donor relations

18 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

2.6 Hum

The system shall enable internal approval of applying for funding. Entity Internal Pledge Note

1 Approval for applying for funding and possibly co-funding with Kara/DRF. Possibly combined with No. 2.4 Hum?

2.7 Hum

The system shall store the funding application. Entity Application

2.8 Hum

The system shall enable associating persons/users to initial assessment and planning phase as members (including field delegates).

1

2.9 Hum

The system shall enable document management (creation from template, template management, uploading, copying, moving, editing, etc.) for documents such as Assessment ToR, Budget, Work Plan, SitReps, Op Plan, funding application, ICRC/IFRC Emergency Appeals, narratives, budget reports.

Documents

1

2.10 Hum

The system shall store the information on the date when application was sent to donor and on the deadline when to expect response + alarm if by DL (i.e. HAVAJ 1,5 months).

Doc (Email + Final version)

2

2.11 Hum

The system shall store the funding decision (positive/negative) and the request for payment.

Document Negative decision: will be archived. Positive decision: will be linked to grant and project.

2.12 Hum

The system shall store the information on the date when to expect the payment from donor.

2.13 Hum

The system shall open both a framework grant (e.g. KAT I and KAT II) and under this projects (Operations) when a positive funding decision has been received. Framework grant can be linked to several projects.

Entity Grant 1 Enables managing framework grants as a single package based on contracts, including reporting dates and requirements.

2.14 Hum

The system shall enable archiving the decision and application documents under country/disaster/donor for a negative funding decision.

Entity 1

19 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

2.15 Hum

The system shall have grant identified with partner (ICRC, IFRC, ONS, HNS, PNS, others), total amount, type of funding MFA (HAVAJ I, II or flash, special conditions, implementation period (months), reporting dl (date), upload of grant decision.

Entity Framework Grant

1

2.16 Hum

The system shall require approval for internal decision document (päätösasiakirja) on the usage of grant (incl. disaster relief fund) before an implementation phase project can be opened in the system (toteutuslupa). Internal decision document contains the information on funding amounts (external and internal).

Entity Internal Pledge Note

1 Internal decision document data can be used e.g. in liquidity management and DRF calculations. TBD: can some of the data come directly from budget?

2.17 Hum

The system shall create a project to track implementation phase information. Requirements for Project key data, see section 3/Dimensions & Other structures.

1

2.18 Hum

Implementation and monitoring phase

The system shall have a project data/document/task checklist (configurable per project type) to show which are the relevant tasks or documents at this phase. User will be able to see open tasks for his/her project/s.

Entity Checklist 1 TBD: checklist for MFA-Hum, EU-Hum, other

2.19 Hum

The system shall enable different status for project (active or closed). This will enable extracting only "active projects".

1

2.20 Hum

The system shall store the agreement with implementing partners (ICRC, IFRC, PNS or HNS).

Document 1 TBD (requirement from donors/MFA, ECHO)

2.21 Hum

The system shall enable building 3-4 main "dimensions of the operation": Programme (Ops+Cash), Human Resource (HR), Material (Logistics), and Other (Monitoring). These will have own process (similar) but distinct and different users. Programme Officer is the coordinator of all.

1

20 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

2.22 Hum

The system shall store the main budget lines as above in a built-in table and enable monitoring possibly with manual input of actuals (future Navision) and manually input forecast.

Entity Operational Budget

1 See also 3.6 Dev and "FRC MFA KAT Monitoring" -excel. Possibly the forecast for HR costs could be retrieved from approved delegate requisitions, and likewise the procurement costs could be retrieved from approved/updated procurement requisitions.

2.23 Hum

Prog The system shall enable documenting cash transfers, including uploading of Pledge Notes/Letters.

1 Transfer of funds process related

2.24 Hum

The system shall enable setting a schedule for partner reporting and cash transfers, with alarm 2 months before hand.

1 See also "Activity & Milestone" in 3.23-3.24.

2.25 Hum

Prog The system shall enable uploading of Eas/PoAs (including revised), sitreps, field reports, field mission reports, maps etc.

Document 1

2.26 Hum

Prog The system shall enable uploading of communication with donor and partners (emails) i.e., approval of changes.

Document 1

2.27 Hum

Prog The system shall enable storing of interim reports (ECHO) and final reports (scanned pdf-package), including proof of submission to donor (email archive).

Document 1

2.28 Hum

Prog The system shall enable overview of operations per region/country, channel (IFRC, ICRC), and person (linked to management) with TBC data.

Entity Ops Overview

1 Dashboard

2.29 Hum

HR The system shall enable updating of HR forecast regularly (manually) with no of delegates sent and approx. estimated expenditure.

Entity HR Plan 2 See 2.22 Hum

2.30 Hum

Material The system shall enable uploading the Pledge Letter (IFRC). Document 2

21 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

2.31 Hum

Material The system shall enable procurement request to be created with country, items, channel, item value, total value and estimated time of arrival (ETA).

Entity Procurement request

1

2.32 Hum

Material The system shall require approval of procurement request based on authorisation levels of organisation.

1

2.33 Hum

Material The system shall enable procurement plan to be created with estimated expenditure based on tendering as above and updating procurement plan regularly (manual) with actual expenditure.

Entity Procurement plan

1/2

2.34 Hum

Material The system shall store the procurement documentation (tendering documentation, shipping documentation, Gift Certificate, Goods Received Note, Commercial Invoice) and confirmation of material actual time of arrival (ATA).

1/2

2.35 Hum

Material The system shall enable document upload of Goods in Kind Pledge.

Document 2

2.36 Hum

Visibility The system shall enable documentation of communication; date, channel, subject link or document (IFRC, ICRC or FRC?).

Document 2

2.37 Hum

Closing, exit and evaluation phase

The system shall ensure a final report has been uploaded (to donor) and possible "approval" (not all, MFA none, ECHO yes).

Document 1

2.38 Hum

System shall enable Evaluation reports (RTE or Final evaluation) to be uploaded.

Document 1

2.39 Hum

The system shall require authorization for (preliminary) closure of project/framework grant, based on the predefined criteria for disaster response projects.

1 Incl. Finance related tasks/aspects (fund balance = 0)

22 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

2.40 Hum

The system shall have a project data/document/task checklist (configurable per project type or donor) to show which are the relevant tasks or documents at this phase. Tasks are user role specific and may relate to administration, finance, quality assurance, etc.

Entity Checklist 1 E.g. (i) Delegate employment termination process (end of mission report received, exit survey completed, debriefing done, field financial reports received, equipment returned, etc.). (ii) Dipecho project closing checklist (see example in separate document). (iii) Closing of the delegation task list (Annex 10E in FRC's Project Manual). (iv) Closure of field finance operations (from Finance and administration manual for FRC field operations).

2.41 Hum

The system shall store audit recommendations, learnings, findings and the implementation plan for recommendations into a database where they can be retrieved and reported per project/partner/donor/etc.

1

2.42 Hum

Donated clothes (Vaateapu)

The system shall store the information on identified project opportunities and tag them to e.g. country or sector level.

1

2.43 Hum

The system shall have a built-in table for project's high level budget (value of clothes, transportation & insurance, distribution costs). Detailed budget will be stored as an Excel.

1

2.44 Hum

The system shall have a checklist for the needed documents, either received from the partner or produced internally.

1 Example: Goods received note and Goods distribution report (from partner), Health certificate (internally by Logistics)

2.3 TO BE DESCRIBED LATER

23 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

ERU

3. Other functional requirements (not cycle phase related)

3.1 Dimensions & Other structures

Project: The system shall have Projects as an entity/dimension. The system shall have basic project data for each project, such as project code and name, start and end dates etc.

1

3.2 The system shall have Partner (e.g. Kenyan Red Cross Society) as an entity/dimension. Items such as risk assessments, contact persons, bank account, etc. will be connected to the partner entity. Subset of "Stakeholder" in general requirement list.

1

3.3 Country: The system shall have Country as an entity/dimension. Countries will be grouped geographically into sub-continents and continents.

1

3.4 Donor: The system shall have Donor as an entity/dimension. Subset of "Stakeholder" in general requirement list.

1

3.5 Project type: The system shall have project type (water and sanitation, earthquake, cholera etc.) as an entity/dimension. The system shall support grouping of project types into a hierarchy (e.g. natural disasters, community development etc. on second level; disasters / development coordination on the top level).

1

3.6 Project class: The system shall have project class (e.g. program, delegate, training, internal etc.) as an entity/dimension.

1

3.7 Channel: The system shall have Channel (e.g. IFRC, ICRC, bilateral) as an entity/dimension.

1

Grant: The system shall have Grant as an entity/dimension. Grant cycle management includes e.g. application creation, contract signing, back-donor reporting.

1

24 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

3.8 Advisor: The system shall have Advisor, set up for each sector, as an entity/dimension.

1

3.9 Project hierarchy: The system shall have a hierarchy structure to group projects together (i.e. to bind sub-projects into larger projects or programmes)

1

3.10 Project linkages: The system shall provide unambiguous linkage between projects and other relevant dimensions. The linkages may be 1-n, n-1 or n-n. Required linkages include: project type, project class, project country, partners involved in the project and their roles (implementing partner/consortium lead or member, etc.), donors involved in the project and their funding and possible administrative expenses, project channel

1

3.11 Reporting Missing mandatory documents: The system shall provide a report that shows by project the missing or non-final mandatory documents based on document metadata and pre-set requirements for the project.

1

3.12 Late financial reports: The system shall provide a report that shows by project the missing financial reports based on pre-set reporting schedule and document metadata.

1

3.13 Late financial reports summary: The system shall provide a report that shows by partner the number of late financial reports and average number of days late.

1

3.14 Report handling time: The system shall provide a report that shows by project and/or region the average number of days from registration of report to delivery into HQ, as well as handling times within HQ.

2

25 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

3.15 Notifications sent to partner: The system shall provide a report that shows by partner and topic the number of notifications sent to partner.

2

3.16 Recommendations: The system shall provide a report that shows the recommendations given to partner (and stored in the system), such as audit and evaluation recommendations, grouped by type. The report will show date of recommendation, planned follow-up date and whether status of the recommendation (implemented, pending, disputed etc.)

2

3.17 Cash transfer report: The system shall provide a cash transfer report, showing amount of cash transferred to the field (based on voucher class) versus the field budget (having cost source = partner) of the project.

1

3.18 Documents and Related Metadata

Document Metadata: The system shall record metadata for documents stored into it, such as: related project, related partner, type (e.g. contract, project plan, indicator tracking table, financial report, audit, evaluation report etc.), version (date, created / modified by).

1

3.19 Searching by Metadata: All implemented metadata fields shall be usable as criteria for searching, filtering and sorting

1

3.20 The system shall have a data/document checklist per cycle phase (configurable per project type) to show which relevant documents are needed at this phase, to facilitate audit and quality review.

1

3.21 Entity members

The system shall enable associating persons/users to concepts/projects/disasters as members. Members' functionality controls who has edit access to the different entities.

1

26 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

3.22 The system shall keep a history log of persons that have been associated to an entity, with information about start/end date and role.

1

3.23 Activity & Milestone

The system shall have an activity and milestone functionality to guide the user through the process cycle phases, reporting schedule (internal/external) incorporated, and to ensure that correct contributions, reviews, updates, and sign-offs take place at key phases. Each activity/milestone either requires or does not require an approval (e.g. signed contract with donor, financial report received from partner). The system shall keep log on approvals/decisions made both in the system and outside of the system.

1

3.24 The system shall support capability to define reporting and audit schedules per donor either on global level or on project level

1 Global level = for instance MFA framework agreement covering approx. 60 projects, one donor deadline for all projects

3.25 The system shall support capability to define reporting and audit schedules per partner (ONS) either on global level or on project level

1 Global level = for instance all projects funded by MFA framework agreement, ONS reporting deadlines are identical

3.26 The system shall support capability to define payment schedules per partner (ONS) either on global level or on project level

1 Partner = ONS, IFRC, ICRC

The system shall support capability to define monitoring schedules per project/programme.

1

3.27 Alerts & notifications

The system shall enable alerts (red flags) based on predefined schedules, for instance where an approval is required or when a deadline is approaching.

1

3.28 Emails The system shall enable user to send emails directly from Outlook to system without having to store them on a local disk

1 E.g. to register partner communication

27 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

3.29 The system shall enable user to add a document stored in the system as an attachment to an Outlook email without having to temporarily store it on a local drive

1 E.g. to register partner communication

3.30 Resource library

The system shall have an area to store templates and guidance for the complete project cycle ("resource library"), visible also on the project cycle pages.

1

3.31 The system shall enable an administrator to configure the structure of the resource library.

1

3.32 The system shall enable adding links to external resources in the resource library.

1

3.33 Consortium The system shall enable the management of consortiums by allowing attaching one or several PNSs to one project.

1

3.34 The system shall enable defining reporting and payment schedules per consortium partners.

1

3.35 Risk management

3.36 Recommendations

The system shall have a recommendations database. It includes linkages to project and to partner as well as the source of recommendations, e.g. audit report, travel report, evaluations, etc. Recommendations can be prioritized.

Entity 1

3.37 Other The system shall have a project type for long-term work with no end date ("business as usual"), such as relationship building, planning (not related to one project only).

2

3.38 The system shall enable storing country or partner specific information that is not related to any project, for example security reports.

1

3.39 The system shall have a learning portal to register and view 1

28 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

learnings.

3.40 The system will have structured search functionality for running ad-hoc queries on the data on the system. This enables end users to drill into the data easily, without needing to develop a lot of "fixed" reports.

1 E.g. "List all projects that have been running in the Latin America with the type 'Floods' during the last three years".

4. Other functional requirements (support process related)

4.1 Delegate recruitment process related

4.1.1 Preparatory phase

The system shall have a built-in table "Delegate Planning Tool" (=Delegate requirement list for planning purposes), implemented in all entities. Delegate Planning Tool enables user to register upcoming recruitment needs (position, duty station, latest start date for the mission, total duration of the mission, funding source, budgeted unit rate, specific requirements, and main project). Recruitment needs are classified as following: highest priority, priority, preferred, heads up, ICRC.

Entity Delegate planning tool

1

4.1.2 Planning phase

The system will enable manager approval of Delegate Planning Tool lines.

1


The system will enable programme officer to generate a recruitment request following manager's initial approval of delegate plan (Delegate Planning Tool line).

1 Approval by a member of the International Operations & Programmes Management Team


The system shall enable putting a recruitment request into a status "inactive" if the recruitment is for some reason dropped.

1

29 (34)

APPENDIX 1


No. 2014-031329

14 January 2015


The system shall have an activity and milestone functionality for delegate recruitment, deployment preparation and employment termination sub-processes (HR team site). The system will alert entity members when an activity is completed or a milestone is approaching, e.g. interviews completed, contract signed, project's administrative kick-off meeting (aloituskokous) is due, briefing given.

1


The system shall record data on when the delegate employment contract was signed (manually input).

1

4.1.7 Planning phase, Partly delegate related

The system shall store the projects' administrative kick-off meeting template.

Entity 1 Kick-off meeting. A common tool for programmes, finance and HR.


The system shall create a delegate project to track delegate -related information based on data given in the recruitment request or manually (donor, channel, type, etc.) after the employment contract has been signed. Requirements for Project key data see section 3/Dimensions & Other structures.

1

4.1.9 Implementation phase

The system shall have a project data/document/task checklist (configurable per project type, e.g. delegate project) to show which are the relevant tasks or documents at this phase. User will be able to see open tasks for his/her project/s.

1 E.g. Delegate deployment preparation process (list of briefing needs, list of equipment needed, host NS invitation received, etc.). Mentioned also in the chapter 1.


The system shall enable alerting entity members when delegate's work contract is ending within the next 6 months.

1 This will work as a reminder for entity members (e.g. programme officer, HR officer) to start planning for a contract renewal, new recruitment, etc.

30 (34)

APPENDIX 1


No. 2014-031329

14 January 2015


The system shall enable alerting entity members when delegate's work contract is ending within the next 3 months.

1 This will work as a reminder for entity members (e.g. programme officer, HR officer) that an appraisal/mid-term review is due.


The system shall have a "whereabouts" functionality to keep track on delegates' travel, trainings, and annual leave.

1


The system shall have an approval workflow for delegates' travel, training and annual leave requests ("whereabouts").

1

4.2 Delegate deployment preparation process related


The system shall store in the resource library the delegate briefing packages per subject (e.g. HR, Finance) and per project type (Disaster response/KAT and Development cooperation/KYT).

1


The system shall have an entity called "Delegate Equipment Requisition" to gather the information on the needed equipment for the delegate.

Entity Delegate Equipment Requisition

2 Currently filled in manually. Enables summaries e.g. for IT and HR. Can be handled also in excel.

4.3 Delegate employment termination process related

4.3.1 The system shall enable storing the delegate end of mission reports.

Document 1

4.4 Field financial report handling process related


The system shall have a place to store the verified field financial report received from the partner (verified = approved by RFAD).

1 E.g. field financial report consists of number of documents shall be stored in a single place connected to the project.


The system shall have a checklist for field financial report to see if everything has been received (balance sheet, income statement, general ledger, journal, bank statement, bank reconciliation).

Document 1


The system shall enable adding comments to the field financial report (e.g. by RFAD) to indicate the state and completeness of

1

31 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

the report.


The system will store the date first version received, the date of final version received, the date of verification (RFAD approval). These shall be linked to milestones described in chapter 3.19 changing the status of the milestone.

1


The system shall have a template for memo voucher/manual journal (muistiotosite).

1


The system shall enable sending of the memo voucher for bookkeeping process, including an alert to accountant.

1


The system shall require approval for memo voucher at different levels (e.g. Desk Officer, HR Officer).

1

4.5 Transfer of funds process related


The system shall have a place to store the cash transfer request received from the partner. This is linked/attached to a field financial report (except for the first payment and Hum projects).

Document 1


The system shall enable adding comments to the cash transfer request (e.g. by RFAD) to indicate the state of the request.

1


The system shall require approval for the cash transfer request by RFAD.

1


The system shall enable generating a payment order based on the CTR or on agreed payment schedule with partner (IFRC, ICRC).

Entity Payment order

1


The system shall require review for the payment order by Finance Control.

1


The system shall enable interfacing the payment order (sent in PDF format to specified email address) into the Account Payables, where it will be reviewed, approved and sent for payment

1 Account Payables system = Basware e-Office

32 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

according to the set hierarchy.

4.6 Travel management process related

4.6.1 Relates to all cycle phases

The system shall have a place to store the field trip plan (per project/entity) including information on traveller, time, destination, purpose of the trip, cost, funding source, budget holder. ToR and agenda for the trip are saved as attachments.

Document/Entity

Work trip plan

1 "Matkasuunnitelma". Field trip is e.g. for monitoring or evaluation purposes.


The system shall require approval for the field trip plan and ToR at different levels (manager, director, secretary general).

1


The system shall have a place to store the field trip report. Document 1


The system shall store field trip recommendations into a database where they can be retrieved and reported per project/partner/etc.

1 "Recommendations Dashboard"


The system shall have a "whereabouts" functionality to keep track on delegates' travel, trainings, and annual leave.

1


The system shall have an approval workflow for delegates' training and annual leave requests ("whereabouts").

1 N.b. travel request/plan is managed as in section 4.5.1 and 4.5.2.

4.7 Procurement process related

5. Non-functional requirements

5.1 Locale Users shall be able to specify the locale to use for their sessions. The default locale is fi_FI

Date/time format, currency

5.2 Ease of use,

33 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

discoverability

5.3 Response time

Forms, editing, searches should be "instant". Longer running task shall provide progress feedback to the user.

5.4 Support and help desk

The supplier shall provide - admin training for customer appointed users - 2nd line of support - self-study material

5.5 Maintainability and portability

- Data models and schema shall be made available to the customer. - Data shall be exportable in an open, documented format - The supplier shall provide installation and setup guides and an maintenance and operations guide for the software

5.6 Tags and taxonomies

Where applicable, entities should be taggable E.g. Zuboumba EQ response project tagged with WatSan, IT/T, Logs

6. Information security

6.1 Technical The application is hosted in the EU (main/backup servers, database, etc.)

1

6.2 All network traffic is properly protected (e.g. https for web traffic) 1 Includes integration protection (https/ssl)

6.3 Administrative

The system shall support assigning roles and privileges to users per FRC documentation

1 Approval limits, control points, roles

6.4 The supplier has an information security management system in place and documented (e.g. ISO 27001)

1

6.5 Backup and restoration procedures are documented and tested 1

6.6 Other The system shall automatically scan uploaded documents for viruses.

1

7. Technical

34 (34)

APPENDIX 1


No. 2014-031329

14 January 2015

requirements

7.1 The system is provided as service (SaaS) 1

7.2 The system is web based and works in modern desktop browsers 1

7.3 The system shall be able to integrate with Finnish Red Cross email services

1

7.4 The system shall provide integration interfaces for other systems, including but not limited to: - MS Dynamics NAV - HR software called REST

1 Integrations are described separately

7.5 The supplier provides development, testing, staging and production environments of the software

1