GUIDE TO SYSTEMS

ENGINEERING
FOR HUMANITARIAN INFORMATION
MANAGEMENT
Guide To Systems Engineering For Humanitarian Information Management,
GICHD, 2021
© GICHD

The content of this publication, its presentation and the designations

employed do not imply the expression of any opinion whatsoever on the
part of the GICHD regarding the legal status of any country, territory or
armed group, or concerning the delimitation of its frontiers or boundaries.
All content remains the sole responsibility of the GICHD.
GUIDE TO SYSTEMS
ENGINEERING
FOR HUMANITARIAN INFORMATION
MANAGEMENT
The Geneva International Centre for Humanitarian Demining (GICHD) is
an international expert organisation based in Switzerland that works to
eliminate mines, explosive remnants of war and other explosive hazards. By
undertaking research, developing standards, and disseminating knowledge,
the GICHD supports capacity development in explosive ordnance-affected
countries. It works with national and local authorities to help them plan,
coordinate, implement, monitor and evaluate mine action programmes. The
GICHD also contributes to the implementation of the Anti-Personnel Mine
Ban Convention, the Convention on Cluster Munitions, and other relevant
instruments of international law. The GICHD follows the humanitarian
principles of humanity, impartiality, neutrality, and independence.
TABLE OF CONTENTS

INTRODUCTION 7
List of abbreviations 9
Key terminology 11
Acknowledgements 12
Quick reference guide to IM system design 13

CHAPTER 1 –
RUDIMENTS OF SYSTEMS ENGINEERING
& INFORMATION MANAGEMENT 14
1.1 Systems engineering definition 15
1.2 Characteristics of an elegant system 17
1.3 Role of the systems engineer 18
1.4 The twelve principles of systems engineering 21
1.5 Systems engineering management 25
1.6 Definition of information management 29
1.7 Waterfall vs agile methods of system development 32

CHAPTER 2 –
SYSTEMS ENGINEERING-BASED DESIGN PROCESS 37
2.1 Project management 39
2.2 Stakeholder consultation / User requirements analysis 51
2.3 Concept of operations 60
2.4 Functional requirements analysis 63
2.5 System requirements definition 71

 5
 CHAPTER 3 –
IMPLEMENTATION STRATEGIES 76
3.1 Data and legacy system migration 77
3.2 Information technology considerations 81
3.3 System risk management 87
3.4 Functional deployment 90
3.5 Organisational change management 91
3.6 Verification and validation testing 92
3.7 Final documentation 93
3.8 Conclusions 94

CHAPTER 4 –
CASE STUDIES 96
4.1 Sistema de Alerta Temprana del valle de Aburrá, Colombia 97
4.2 Enterprise GIS for OSCE Special Monitoring Mission to Ukraine 108
4.3 Information Management System for Mine Action 120
4.4 Open-source IMS for mine action 130

6 
INTRODUCTION
In the context of rapidly unfolding humanitarian emergencies and high-
risk, post-conflict environments, the effective management of information
is critical. Unfortunately, information management (IM) systems can fail to
meet stakeholder requirements in these contexts if they are not sufficiently
understood before deployment. Humanitarian IM systems often fail to meet
the needs of their users, and are regularly delivered over budget and later
than expected, because of poor design and planning.

The result can be disappointment, missed opportunities and rejection of the

system by users. This guide aims to prevent that, by introducing the core
principles of systems-based engineering within the context of humanitarian
emergencies and post-conflict environments.

When effectively applied, information management systems serve to enable

a process, a capability, or a result. It is critical that an IM system comes
from the part of the organisation that will benefit from it, with sponsorship
or buy-in from senior leadership who sees the value in what the system will
enable. When an IM system is initiated independently (such as by an IM or
technology team), it is all too often destined to fail.

Systems engineering (SE) is a well-established method for improving the

likelihood of success of technologically risky projects. Systems engineering
seeks to understand the big picture, and to identify the cause-and-effect
relationships between the various elements of any overall system. It also
recognises the importance of understanding the short- and long-term
consequences of any action, as well as the associated risks and costs. SE is
a structured and all-encompassing design and management process, which
considers both the business and the technical interests of stakeholders
throughout the life cycle of any proposed system.

Introduction 7
 This guide can be used when deploying a new IM system as well as when
upgrading or improving an existing system. In this publication, the GICHD
introduces theoretical and practical best practices from around the world,
and provides tools that will improve the success of IM systems deployed in
support of mine action, peace monitoring, disaster risk reduction and other
conflict and post-conflict humanitarian initiatives.

8 Introduction
LIST OF ABBREVIATIONS
AMVA Metropolitan Area IKMAA Iraqi Kurdistan Mine
of the Aburrá Valley Action Agency
(Colombia)
IM Information
CDF Custom defined field management

ConOps Concept of IMAS International Mine

operations Action Standards

COTS Commercial off-the- iMMAP Information

shelf Management and Mine
Action Programme (an
EGIS Enterprise international not-for-
geographic profit organisation)
information system
IMS Information
EORE Explosive ordnance management system
risk education
IMSMA Information
FRA Functional Management System
requirements for Mine Action
analysis
MOEs Measures of
FRD Functional effectiveness
requirements
definition MOPs Measures of
performance
GIS Geographic
information system NASA National Aeronautical
and Space
GICHD Geneva International Administration (of
Centre for the United States of
Humanitarian America)
Demining

Introduction 9
 NMAC National mine action SMM Special Monitoring
centre Mission to Ukraine
(OSCE)
NOAA National Oceanic
& Atmospheric SRD System requirements
Administration (United definition
States)
TNMAC Tajikistan National Mine
OP Open source Action Centre

OSCE Organization ToC Theory of change

for Security and
Cooperation in Europe UNMAS United Nations Mine
Action Service
SaaS Software as a Service
WBS Work breakdown
SE Systems engineering structure

SEM Systems engineering

management

SIATA Sistema de Alerta

Temprana de Medellín y
el Valle de Aburrá (Early
Warning System of
Medellín and the Aburrá
Valley)

An exhaustive and updated list of acronyms and abbreviations related to the

Systems Engineering Body of Knowledge is available at:
[Link]

10 Introduction
KEY TERMINOLOGY
A number of words used in this guide have specific meanings. They include:

• Concept of operations: the overall high-level concept of how

the system will be used to meet stakeholder expectations,
and that serves as the basis for subsequent definition
documents and provides the foundation for long-range
operational planning activities.

• Engineered system: a system designed or adapted to interact

with an anticipated operational environment to achieve one
or more intended purposes while complying with applicable
constraints.

• Stakeholders: people and organisations that have an interest

in a system, or may be affected by that system. These might
include internal and external users, data contributors, donors
and direct / indirect beneficiaries, including communities,
governments and civil society organisations.

• System: a combination of interacting elements organised to

achieve one or more stated purpose.

• Systems engineering: a transdisciplinary and integrative

approach to enable the successful realisation, use, and
retirement of engineered systems, using systems principles
and concepts, and scientific, technological, and management
methods.

An exhaustive and updated list of terminology related to the Systems

Engineering Body of Knowledge is available at:
[Link]

Introduction 11
 ACKNOWLEDGEMENTS
The Geneva International Centre for Humanitarian Demining (GICHD)
expresses its utmost gratitude to the people and institutions who so
generously collaborated to produce this guide by sharing experiences,
resources and expert feedback.

Content of the guide was written by Firoz Verjee (lead author), Steve Hellen,
Anna Paiuc, Wendi Pedersen and Sulaiman Mukahhal (GICHD); and Arie
Claassens and Mark Steyn (iMMAP).

Expert review was offered by: Richard Brittan and Tim Buckley (Alcis);
Olivier Cottray (Esri); Arie Claassens (iMMAP); Steve Hellen and Abigail
Jones (GICHD); and Michael Johnson (SE-Training).

Case studies were shared by: the Organization for Security and Co-operation
in Europe Special Monitoring Mission to Ukraine, United States Department
of State’s Bureau of Conflict and Stabilization Operations, United States
National Weather Service, Tajikistan National Mine Action Committee,
United Nations Mine Action Service, iMMAP and the Iraqi Kurdistan Mine
Action Agency.

This publication was made possible thanks to the financial support of the
German Federal Foreign Office and the government of Switzerland. The
ideas, opinions, and comments in this guide are entirely the responsibility of
its authors and do not necessarily represent German or Swiss government
policy.

12 Introduction
QUICK REFERENCE GUIDE
TO IM SYSTEM DESIGN
A quick reference guide is provided with this publication as a checklist for
IM systems engineers and project managers. It is recommended for use in
conjunction with the detail found in this guide, and with further information
available through the materials listed on this publication’s resource site,
[Link]

Introduction 13
 CHAPTER 1 –
RUDIMENTS
OF SYSTEMS
ENGINEERING &
INFORMATION
MANAGEMENT

14 Chapter 1 – Rudiments of systems engineering & information management

1.1 SYSTEMS ENGINEERING
DEFINITION
The field of systems engineering (SE) emerged in the 1940s and was
first used for the robust design of complex military and energy systems.
Today, SE is employed in a wide range of civilian applications, including
space exploration, transportation, medicine, education, electronics, heavy
industry, and information management.

SE is rooted in the concept of systems thinking, a holistic approach that

considers the interdependence of various components of any system of
interest. Systems thinkers seek to understand the big picture and identify
the cause-and-effect relationships between the various elements of any
overall system. They also recognise the importance of understanding
the short- and long-term consequences of any action, as well as their
associated risks and costs. (International Council on Systems Engineering,
2015) Most importantly, they know that by disassembling a complex system
into less-complex subsystems, it will be easier to solve design challenges
and manage project risks (strategic, technical and financial).

There are many classical and modern definitions of the term systems
engineering. In this guide, we adopt the following:

Systems Engineering is a transdisciplinary and integrative

approach to enable the successful realization, use, and
retirement of engineered systems, using systems
principles and concepts, and scientific, technological, and
management methods. (International Council on Systems
Engineering, 2020)

The above quote suggests that SE is a structured and all-encompassing

design and management process, which considers both the business and
the technical interests of stakeholders throughout the life cycle of any
proposed system.

Chapter 1 – Rudiments of systems engineering & information management 15

 In our context, the word ‘system’ is defined as ‘a combination of interacting
elements organised to achieve one or more stated purposes.’ (ISO/IEC/
IEEE 15288, 2015) These elements can be physical or conceptual, or a
combination of both. (International Council on Systems Engineering,
2020) For example, an enterprise-wide geographic information system will
integrate a suite of products (hardware and software), people, processes,
information, services, standards, techniques, facilities, and communications
in order to achieve its objectives.

The remainder of this section introduces some important foundational

knowledge about SE and information management (IM); take some time to
study this before beginning to apply the tools and methods explained in the
rest of the publication.

16 Chapter 1 – Rudiments of systems engineering & information management

1.2 CHARACTERISTICS OF
AN ELEGANT SYSTEM
It is important to acknowledge that IM systems are typically composed of a
single or combination of (1) open-source, (2) commercial, and (3) custom-
built components. Regardless of whether an IM system is constructed
out of existing or custom technologies, the goal remains the same: to
implement a solution that is robust in application, graceful in operation,
efficient, economical, and timely.

Ultimately, any system should be elegant – that is, have the qualities of
being ingenious, simple, appealing, and graceful. Elegance does not
preclude the need for systems to also be resilient, secure and durable
– indeed, these traits are all essential to the overall outcome of any IM
project. Most importantly, elegant systems are not built through chance or
coincidence; they are built using an intentional process, and by a team with
the necessary resources, skills, and discipline. (NASA, 2018)

But is this realistic within a conflict or post-conflict humanitarian

context? The answer is YES! Even when timelines are tight, staff are
overwhelmed, and funding is limited – organisations should still aim to
deploy elegant IM solutions. Elegance should be considered essential
to the successful deployment of any IM system. The skilled systems
engineer understands how to achieve this seemingly lofty aspiration within
the extreme pressures of a humanitarian emergency or a peacebuilding
initiative in a fragile region.

‘Systems engineers aren’t superheroes,

even though some organisations make
theirs out to be! But they can achieve
a lot when empowered to do so.’
Michael Johnson, SE-Training GmbH

Chapter 1 – Rudiments of systems engineering & information management 17

 1.3 ROLE OF THE SYSTEMS
ENGINEER
Systems engineers are valuable members of a project team because they
balance stakeholder interests, resolve conflicting objectives, manage risk,
navigate constraints, and strive for an elegant result. The exact role and
responsibility of the systems engineer may vary depending on the size
and complexity of each project and from phase to phase of the project’s
life cycle. And, while large projects may require one or more dedicated
systems engineers, smaller deployments may combine the functions of a
project manager and a systems engineer, to create what might be called a
‘project lead’. Except for the most basic IM deployments, it is not advisable
to conflate the role of the project lead / systems engineer with that of an IM
officer – these roles should ideally remain distinct until the system is fully
operational.

[Note: It is quite possible for the same person to take on the role of project
lead, and once the system is operational to then utilise the system in the
role of IM officer. Indeed, IM officers are increasingly expected to acquire
systems engineering skills, making this approach more the norm than the
exception. Instead of being limited to their traditional function of providing
IM products and services, the role of IM officers has shifted towards being
a service enabler – a logical step towards taking on the role of systems
engineer. This has significance in the context of humanitarian information
management systems since it helps address the requirement for timely
information in high-pressure environments. But, the perspective and
responsibilities of a systems engineer are quite different to that of an IM
officer, and must be respected if the same person is asked to perform both
roles in an organisation.]

18 Chapter 1 – Rudiments of systems engineering & information management

Specifically, the role of the systems engineer includes:

1. Leading the development of the concept of operations and

resulting system architecture;
2. Creating project boundaries;
3. Defining system requirements;
4. Leading the technical planning effort;
5. Consulting key stakeholders;
6. Documenting the technical plans, requirements,
specifications, and acceptance of documents.

The systems engineer is an inter-disciplinarian ‘skilled in the art and science

of balancing organizational, cost, and technical interactions in complex
systems’. (NASA, 2016)

So how does the role of a systems engineer fit within the overarching
process of project management? As illustrated in the figure below, the
systems engineer is focused on the technical aspects of a project, as
opposed to the programmatic, financial, and contractual aspects of
the project (collectively referred to as project planning & control). The
systems engineer will have overlapping interests with other members of a
project management team in common aspects such as risk management,
scheduling, and stakeholder consultation.

Chapter 1 – Rudiments of systems engineering & information management 19

 SYSTEMS
ENGINEERING
System Design
• Use Case Definition COMMON PROJECT PLANNING
• ConOps AREAS & CONTROL
• Data Modelling
• Requirements Definition • Stakeholder • Resource Management
Technical Consultation • Scheduling
Management • Risk • Cost Analysis & Planning
• Planning Management • Vendor Selection
• Interfacing
• User Training/Support • Task & Procurement
Definition • Contract Management
System Realisation
• Implementation
• Monitoring
• Integration
• Verification
• Validation
• Transition

Figure 1.1 – SE in the context of overall project management

(NASA 2016 & SE-Training, 2020)

As noted above, the precise role of a systems engineer can change from
project to project, but his / her primary role is to support technical decision-
making within the project management process. This is done according to a
set of well-established principles.

20 Chapter 1 – Rudiments of systems engineering & information management

1.4 THE TWELVE PRINCIPLES
OF SYSTEMS ENGINEERING
The role of the systems engineer is perhaps most effectively understood
by reviewing the twelve SE principles as defined by the US National
Aeronautical and Space Administration (NASA):

Principle 1 – Interdisciplinarity: systems engineering integrates various

disciplines with applicable budget and schedule constraints. The systems
engineer is expected to deliver an elegant solution on budget and on
time using multidisciplinary knowledge, and a wide array of tools and
techniques.

Principle 2 – Manage complexity: the systems engineer must manage

the complexities of an organisation’s mission and the complexities of its
desired system. These are interdependent and should not be managed as
mutually exclusive. It is not possible to design an effective system without
understanding the mission that it will support, or the stakeholders involved
in that mission.

Principle 3 – Iterative and progressive: no matter how diligent the

systems engineer is at the start of a project, there will still be knowledge
gaps that will be filled as the system is developed; SE provides the
framework to decide if and how to improve the original design, with a
continuously improving understanding of requirements.

Principle 4 – Comprehensive: systems engineering has a critical role

through the entire system life cycle. Starting from conceptualising a system
based on the needs of diverse stakeholders, then modelling and analysing
various designs of that system, then building and testing that system, then
deploying and operating that system, and finally to decommissioning that
system – SE supports planning from cradle to grave.

Chapter 1 – Rudiments of systems engineering & information management 21

 Principle 5 – Formal process based on fundamentals: systems
engineering should incorporate physical, logical, mathematical, and
sociological truths in the design and deployment of any system. And,
because systems should respect the maturity of their users’ experience,
systems engineers need to enforce these fundamentals; that is, by making
sure that inexperienced organisations follow more formal processes when
operating their systems, as compared to experienced organisations (who
may already have the same controls).

Principle 6 – Culturally respectful: systems engineering respects the

discipline of interactions within the organisation, including its culture.
Any system is informed by, and will ultimately mirror, the realities of the
environment in which it will be used. The systems engineer must therefore
help the project manager to resolve knowledge gaps or organisational
barriers, to avoid flaws in system design and operation.

Principle 7 – Informed decision-making: a system will only be as good

as the completeness of understanding amongst the individuals involved in
the SE process; the systems engineer strives to promote informed decision-
making by involving essential stakeholders and consulting best practices
throughout the SE process.

Principle 8 – Legal and policy compliance: both policy and law must
be properly understood to not overly constrain or under constrain system
implementation. The systems engineer is obliged to understand applicable
policies and laws to ensure the system is legally compliant. Policies tend
to be more flexible than laws, since they are often determined by the
organisation that will use the system, and can therefore be adapted around
the system when appropriate and in consultation with policymakers. Laws
can be more onerous, as they are unlikely to be changed to accommodate
any particular system.

Principle 9 – Risk management: systems engineering decisions often

have to be made with an imperfect understanding of the system context,
and a recognition that there will always be knowledge gaps even as
understanding improves. It is therefore critical to manage this uncertainty
using risk models throughout the SE process.

22 Chapter 1 – Rudiments of systems engineering & information management

Principle 10 – Verification: systems engineers are obliged to test the
functionalities to ensure that they comply with the system requirements –
that is, to verify that a system achieves what was operationally defined as
acceptable performance.

Principle 11 – Validation: stakeholder expectations may or may not have

been adequately reflected in the system requirements, and SE requires the
systems engineer consult with various users before deploying any system
to validate their level of acceptance.

Key point: SE distinguishes between the verification of the system

requirements, and the validation of stakeholder expectations.

Principle 12 – Time sensitivity: particularly in the domain of IM systems,

design decisions are very much constrained to the state-of-the-art in
technology at the time of the design process. The rapid advancement of
technologies may mean that the system will be out of date by the time
it becomes operational. The systems engineer is aware of time frame-
decision constraints, and endeavours to mitigate their impact throughout
the SE process.

These twelve core principles apply to the simplest and to the most complex
of systems; for an exhaustive analysis of the theoretical and practical
implications of these principles, the interested reader may wish to refer to
(NASA, 2018).

Chapter 1 – Rudiments of systems engineering & information management 23

 PRINCIPLES FOR DIGITAL DEVELOPMENT:

In addition to NASA’s twelve principles of systems engineering, also

consider the ICT4D1 community’s nine principles for digital development
([Link]

1. Design With the User.

2. Understand the Existing Ecosystem.
3. Design for Scale.
4. Build for Sustainability.
5. Be Data Driven.
6. Use Open Standards, Open Data, Open Source, and Open
Innovation.
7. Reuse and Improve.
8. Address Privacy and Security.
9. Be Collaborative.

1 ICT4D = Information and communications technology for development.

24 Chapter 1 – Rudiments of systems engineering & information management

1.5 SYSTEMS ENGINEERING
MANAGEMENT
Let us now explore the concept and rationale behind systems engineering
management. As illustrated in the figure below, the term refers to the
integration of three types of activities required to build an effective system:

DEVELOPMENT
PHASING

Life Cycle
Baselines
Planning
SYSTEMS
ENGINEERING
MANAGEMENT

SYSTEMS
LIFE CYCLE
ENGINEERING Integrated INTEGRATION
PROCESS Teaming

Figure 1.2 – Three activities of systems engineering management.

Figure modified by the GICHD and based on (US DoD, 2001)

Chapter 1 – Rudiments of systems engineering & information management 25

 Take a moment to study the figure above (which is referred to as a three-set
Venn diagram), and you will observe that:

• Development phasing controls the design process and

provides baselines that coordinate design efforts. It serves
two major purposes: (1) to control the design effort (by
baselining each level of development), and (2) to connect
the technical management effort with the overall acquisition
effort (by defining the event milestones and deployment
timelines).

• Systems engineering process refers to the comprehensive,

iterative, and robust problem-solving techniques that
aid in developing a system which will meet stakeholder
needs.

• Life cycle integration ensures that a system is designed to

remain viable throughout its life. The eight primary life cycle
functions of SE are: development, production, deployment,
operation, support, disposal, training, and verification.

Collectively, the intersection of these three activities is defined as systems

engineering management (SEM). The economic argument for employing
SEM is compelling, since multiple studies have shown that because the life
cycle cost of most projects is usually determined by the design stage, the
cost to change the system design becomes progressively more expensive
later in the life cycle. As the cost curves in the figure below illustrate, only a
small percentage (approx. 15% on average) of overall project cost is incurred
during the conceptual stage and design of a typical system but, at the
same point in time, a large percentage (more than 75%) of the overall cost
will be committed / determined. It is therefore very cost effective to apply
SEM from the very initial stages of a project. As a general rule of thumb,
the more complex and essential a system is to a group of stakeholders, the
more rigorous and justifiable is the application of SE management.

26 Chapter 1 – Rudiments of systems engineering & information management

 2.0 Fundamentals of Systems Engineering

100%

Cumulative Percentage Life Cycle Cost against Time

90%
90%
75% 500–1000× 100%
80% e
Li f
ed ts
it t os
70% m
m le C Operations
C o C yc 20–100× on through
60% c ti Disposal
re
n Di
45% sig
50%
e De
ng
3–6× C ha ed ) 50%
40% to et e d
st pl end
Co m p
30% Co E x Prod/Test
% ts
os
20% (C
Design
Concept 20%
10% 15%
8% Develop
0%

MCR SRR SDR PDR CDR SIR ORR DR/DRR

Time

MCR Mission Concept Review CDR Critical Design Review

SRR System Requirements Review SIR System Integration Review
SDR System Definition Review ORR Operational Readiness Review
PDR Preliminary Design Review DR/DRR Decommissioning/Disposal Readiness Review

Adapted from INCOSE-TP-2003-002-04, 2015

Figure 1.3 – Life cycle cost from early phase decision-making. (NASA, 2016)
FIGURE 2.5-1 Life-Cycle Cost Impacts from Early Phase Decision-Making

Even in a relatively basic deployment of off-the-shelf IM solutions within

integration. Therefore, the human element is some-
the
2.7 Competency Model for
thinghumanitarian
that integration andcontext, the cost
systems engineering pro- curves Systems
will look the same as above.
Engineers
Yet,
cessesprojects
must [Link] begin
The definition of “system”with
in the acquisition of hardware and
NPR 7123.1 is inclusive; i.e., a system is “the combi-
software, the delivery of training, TABLE and 2.7-1theprovides a summary of the Competency
collection of data – not
nation of elements that function together to produce Model for Systems Engineering. For more informa-
with the disciplined
the capability required to meet a design of system
need. The elements tion onrequirements!
the NASA SE Competency SEM strives
model refer to:to
ensure
include allthat functional
hardware, requirements
software, equipment, facilities, determine technological procurement,
[Link] .
personnel, processes, and procedures needed for this
and not vice versa, to avoid the costs associated
purpose. For additional information and guidance
with partial or total system
There are four levels of proficiencies associated with
failure.
on his, refer to Section 2.6 of the NASA Expanded each of these competencies:
Guidance for Systems Engineering at [Link]
[Link]/web/se/doc-repository. • Team Practitioner/Technical Engineer
There is an optimal amount of investment in SEM for a project, and up to
• Team Lead/Subsystem Lead
a 7:1 return on investment in SE. That •is,Project
for each
Systems dollar
Engineer invested in SEM,
• Chief Engineer
there can be up to $ 7.00 in savings. Research also shows that the optimal
investment in SEM for a typical system is about 14% of overall project cost,
asNASA
illustrated
SYSTEMSin the figuresHANDBOOK
ENGINEERING below. 13

Chapter 1 – Rudiments of systems engineering & information management 27

 2.0
1.9
1.8
Actual/Planned Cost
1.7
Actual/Planned Schedule
1.6
1.5
Ra�o

1.4
1.3
1.2
1.1
Programmes that finish
1.0
on-budget and on-schedule
0.9
0.8
0% 5% 10% 15% 20% 25% 30%

Equivalent SE Effort (ESEE) as % Program Cost

Figure 1.4 – Correlation of SEM effort as % of programme cost. (Honour, 2013)

While the optimal ratio of investment in SEM will vary from project to
project, there are significant returns with committing appropriately to a
systems-based approach; it is possible to overdo systems engineering! The
goal is to make the right level of commitment during the conceptualisation
and design stages, to manage project risk before the project team attempts
to deploy their system. This commitment to SEM then supports the team
throughout the life cycle of the system, improving the likelihood that it will
be completed (a) on budget, (b) on time, and (c) with high levels of user
acceptance.

Bear in mind the definition, principles, roles and management of SE as you

study the rest of this guide. This section concludes by defining IM within the
context of SE, and comparing two common forms of system development.

28 Chapter 1 – Rudiments of systems engineering & information management

1.6 DEFINITION OF
INFORMATION MANAGEMENT
There is a wide variety of definitions of the term information management.
The Cambridge Business English Dictionary defines it simply as, ‘the
process of collecting, organizing, storing, and providing information within
a company or organization.’ (CUP, 2021) IM requires the ongoing collection,
analysis, and timely provision of valuable information for a defined set of
stakeholders. This information contributes to the understanding of, and the
ability to make, decisions regarding:

• The nature and characteristics of an organisation’s

operational environment and its rate of change;
• The implications of the operational environment for an
organisation’s stakeholders (e.g. affected populations, partner
organisations and governments);
• The needs, requirements and preferences of stakeholders;
• The status of an organisation’s assets and ability to act;
• The prioritisation of actions and allocation of resources; and
• The progress towards the achievement of targets.

Information management (IM) in mine action refers to the process

of defining and continually improving information requirements from
all relevant stakeholders and to the subsequent collection, validation,
storage, analysis and dissemination of timely, accurate and easy-to-
access information that meets these requirements.

The ultimate goal of IM is to deliver information products to

stakeholders. To be effective, IM therefore depends on the close
collaboration and involvement of all stakeholders, both internal and
external, with an interest in the mine action programme.

Source: UNMAS 2020 [Link]

IMAS_05-10_Ed2-Am1_02.pdf

Chapter 1 – Rudiments of systems engineering & information management 29

 Understanding who needs what information, how they will analyse it and
what they intend to do with it, is essential to the success of any IM system.
Different users may need the same data for different purposes. This in turn
may influence the accuracy, frequency and format in which data is collected
and reported. IM is not the sole responsibility of an IM department.
Responsibility lies with those who will use the resulting information (and
who must specify their information requirements), those who collect it (and
who must comply with requirements), those who store, secure, analyse
and disseminate it, and those responsible for designing, maintaining and
overseeing the overall IM system.

Ineffective IM can force decision-making based on intuition rather than

evidence. A lack of information may discourage decision makers from
taking efficient decisions, steering them towards unnecessarily cautious
positions. An inability to measure performance impedes transparency and
opens the door to corruption and inefficiency.

WHY IM MATTERS

Creating an effective IM system in humanitarian action can serve to

increase efficiency, strengthen operations, enable better decision-
making, and ultimately, contribute to improved outcomes.

It is important for all stakeholders, including senior management,

to invest time to understand the merits of an effective IM system
and set organisational parameters that will enable its success. IM
systems all too often fail during implementation or uptake or come in
over budget. Indeed, the CHAOS report 2015 showed that only 30%
of all technology projects succeed. This percentage is even lower
for bigger projects. (The Standish Group, 2015) Furthermore, the
majority of large technology projects tend to run 45% over budget
and 7% over time. (Bloch, Blumberg, & Laartz, 2012) To reduce the
risk of incurring extra costs, it was demonstrated that there is an
inverse relationship between time spent on systems engineering and
cost overruns. (SEBok, 2021) More up-front preparation, planning,
and design on a project will reduce future expenditure as the cost

30 Chapter 1 – Rudiments of systems engineering & information management

 of making changes increases exponentially in the later stages of a
project.

To mitigate these costs and risks, buy-in from and active engagement
of senior management to set a clear strategy is critical to successfully
delivering a quality IM system.

While the aforementioned points apply across sectors, the

humanitarian sector has its own particularities. Information
management systems for humanitarian action have evolved a lot
during the last 20 years but some work is still needed, especially in
the exchange of information between headquarters and the field.
Due to the urgency of many humanitarian settings, having already
allocated time and resources in order to have a robust IM system,
will contribute to a more efficient and cost-effective response.
(Schofield, 2003)

IM is commonly and mistakenly seen as an isolated task belonging to the

IT department – limited to hardware and software maintenance and data
archiving. Instead, IM should be understood as a basic function of every
decision maker at every level in an organisation.

All data is collected for a purpose. If it does not satisfy that purpose,
then the system fails. Combining operational, quality and information
management as facets of a single activity is increasingly recognised within
mine action programmes and humanitarian initiatives in general. The
future will see an increasing emphasis on a common understanding of
the interconnectedness of these functions and the need for humanitarian
managers to understand, and apply, principles of all three (operational,
quality, and information management) throughout their work.

Chapter 1 – Rudiments of systems engineering & information management 31

 1.7 WATERFALL VS AGILE
METHODS OF SYSTEM
DEVELOPMENT
Before concluding this review of the rudiments of systems engineering
and information management, we shall explore the two most common
approaches to system development: waterfall vs agile. Although these
development models are primarily employed within the context of
software engineering, they are equally relevant in the wider context of
systems engineering. And irrespective of which model is employed, the SE
process is neither static nor inflexible; indeed, the process must always be
responsive to change, where practicable.

The waterfall method is sequential in nature and requires a development

team to advance to the next phase of development or testing only if the
previous step has been completed successfully. So, if a project’s system
requirements are stable and well defined, the waterfall method is typically
preferable. This is the traditional form of system development and is known
to deliver results that are robust, fully documented, and resistant to ‘mission
creep’ (overexpansion of original system requirements). Especially because
a new system will have complex interdependences with other systems, the
waterfall method is often preferable in order to guarantee compatibility.

The agile method is iterative in nature and allows a project team to

undertake system development and testing activities concurrently. When
the system requirements are constantly evolving and cannot be fully defined
at the start of the project, the agile method is preferable. Because it is
particularly client oriented and capable of accommodating changing needs
during the development cycle, it is best suited to dynamic environments.

There has been an unmistakable trend towards greater use of agile versus
waterfall methods. (Dima & Maassen, 2018) While there are many reasons
for this, one that is particularly relevant to the humanitarian sector is the
growing maturity of modular technology components. Such components

32 Chapter 1 – Rudiments of systems engineering & information management

can be configured and adapted to fit specific needs without necessarily
requiring complete custom development. The ability to configure system
requirements allows for a more adaptable and more agile approach to
systems engineering.

The table below summarises the key differences between the agile and
waterfall system development methods, extracted from (GURU99, 2021):

AGILE WATERFALL

Separates the project development life Development process is divided into

cycle into segments called sprints. distinct phases.

Waterfall methodology is a sequential

Follows an incremental approach.
design process.

Waterfall is a structured software

Agile methodology is known for its development methodology so at times it
flexibility. can be comparatively less responsive to
real-time project dynamics.

Can be considered as a collection of many

Will be completed as one single project.
different projects.

Quite a flexible method allowing changes

There is a rigorous change control
to be made in the project development
process in cases where requirements
requirements even if the initial planning
must change after development starts.
has been completed.

Follows an iterative development

approach. Because of this, planning, All the project development phases such
development, prototyping and other as designing, development, testing, etc.
development phases may appear more are completed only once in this model.
than once.

The test plan is rarely discussed during

The test plan is reviewed after each sprint.
the test phase.

Ideal for projects which have definite

A process in which the requirements are
requirements and where changes are not
expected to change and evolve.
expected.

Testing is performed concurrently with The testing phase comes after the build
development. phase.

Chapter 1 – Rudiments of systems engineering & information management 33

 AGILE WATERFALL

Introduces a product mindset where the

This model shows a project mindset
product satisfies the needs of its end
and places its focus completely on
customers and changes itself as per the
accomplishing the project.
customer’s demands.

Works exceptionally well with time & Reduces the risk in firm fixed price
materials or non-fixed funding. It may contracts by getting risk agreement at the
increase stress in fixed-price scenarios. beginning of the process.

Prefers small but dedicated teams

Team coordination / synchronisation is
with a high degree of coordination and
very limited.
synchronisation.

Requirements are prepared by the

Requirements are prepared by a business
product’s owner and their team on a daily
analyst before the start of the project.
basis during a project.

The test team can take part in changes to It is difficult for the test team to initiate
the requirements without a problem. any change in requirements.

A detailed description is needed to

Description of project details can be
implement this software development
altered any time during the process.
approach.

Team members are interchangeable; as a

In this method the process is always
result, they work faster. There is also no
straightforward, so the project manager
need for project managers because the
plays an essential role during each stage.
projects are managed by the entire team.

34 Chapter 1 – Rudiments of systems engineering & information management

REFERENCES
Bloch, M., Blumberg, S., & Laartz, J. (2012, October 1). Delivering large-
scale IT projects on time, on budget, and on value. Retrieved September
17, 2021, from McKinsey Digital: [Link]
functions/mckinsey-digital/our-insights/delivering-large-scale-it-
projects-on-time-on-budget-and-on-value

Cambridge University Press. (2021). Cambridge Business English Dictionary.

(Cambridge University Press) Retrieved August 18, 2021, from https://
[Link]/dictionary/english/information-management

Dima, A. M., & Maassen, M. A. (2018). From Waterfall to Agile software:

Development models in the IT sector, 2006 to 2018. Impacts on
company management. Journal of International Studies, 11(2), 315-
326. doi:10.14254/2071-

Guru99. (2021). Agile Vs Waterfall: Know the Difference Between

Methodologies. Retrieved February 23, 2021, from [Link]
[Link]/[Link]

Honour, E. C. (2013). Systems Engineering Return on Investment (Ph.D.

Thesis ed.). South Australia, Australia: University of South Australia.
Retrieved April 14, 2020

International Council on Systems Engineering. (2015). INCOSE Systems

Engineering Handbook: A Guide for System Life Cycle Processes and
Activities (4th ed.). (D. D. Walden, G. J. Roedler, K. J. Forsberg, R. D.
Hamelin, & T. M. Shortell, Eds.) San Diego, California, USA: John Wiley
& Sons, Inc.

International Council on Systems Engineering. (2020). Systems Engineering.

Retrieved April 6, 2020, from [Link]
engineering/system-and-se-definition/systems-engineering-definition

Chapter 1 – Rudiments of systems engineering & information management 35

 ISO/IEC/IEEE 15288. (2015). Systems and software engineering — System
life cycle processes. Geneva: ISO. Retrieved February 28, 2021, from
[Link]

NASA. (2016). NASA Systems Engineering Handbook. Washington, DC:

NASA. Retrieved June 15, 2020, from [Link]
default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf

NASA. (2018). Engineering Elegant Systems: Theory & Practice of

Systems Engineering (2 Volumes). NASA Marshall Space Flight
Center. Huntsville: National Aeronautical and Space Administration.
Retrieved April 8, 2020, from [Link]
SystemsEngineeringPrinciples

Schofield, R. (2003). Information systems in humanitarian emergencies.

Humanitarian Practice Network (HPN)(18 (March 2021)), 17-18.
Retrieved September 17, 2021, from [Link]
information-systems-in-humanitarian-emergencies/

SEBok. (2021). Economic Value of Systems Engineering. Retrieved

September 17, 2021, from [Link]
Value_of_Systems_Engineering

SE-Training. (2020). Presentation - SE Foundations: Decision & Risk

Management. Geneva: SE-Training GmbH

The Standish Group Intenational. (2015). CHAOS report 2015. Retrieved

September 17, 2021, from The Standish Group: [Link]
com/sample_research_files/[Link]

United States Department of Defense. (2001). Systems Engineering

Fundamentals (1st ed.). (D. S. College, Ed.) Fort Belvoir, Virginia, USA:
Defense Acquistion University Press, p. 4

36 Chapter 1 – Rudiments of systems engineering & information management

CHAPTER 2 –
SYSTEMS
ENGINEERING-BASED
DESIGN PROCESS

Chapter 2 – Systems engineering-based design process 37

 Designing an information management system is a process that is
multidisciplinary, iterative, and highly consultative, and is supported by
specific activities related to project management, monitoring and evaluation.
This chapter explores the systems engineering (SE)-based design process
within the context of humanitarian information management (IM) systems,
such as those described in the final chapter of this guide.

This process is – as the reader would expect – quite systematic! Systems

engineers like to stress the need for:

• Adopting an interdisciplinary approach to designing a new

system;

• Understanding the user requirements fully before attempting

the design process;

• Testing the system to ensure stakeholder satisfaction;

• Considering the complete life cycle of the system, including

operations and decommissioning;

• Providing full documentation to the system operators.

These critical elements are achieved through effective:

1. Project management.

2. Analysis of user requirements.

3. Definition of functional requirements.

4. Definition of system requirements.

Collectively, these process elements allow systems engineers to attain a

good design. These are now discussed in more detail.

38 Chapter 2 – Systems engineering-based design process

2.1 PROJECT MANAGEMENT
As noted in Chapter 1.3, the field of systems engineering is quite distinct
from that of project management. Systems engineers are nevertheless
responsible for a range of technical project management and planning
considerations. This section reviews some of the most common
considerations; however, the reader is also advised to consult donor-specific
project management requirements where applicable.

A. THEORY OF CHANGE

If you are deploying a donor-funded system, you will probably need

to develop or use a theory of change to plan and then evaluate your
system’s success. Increasingly, government agencies, international non-
governmental organisations (NGOs), UN agencies, and other major
humanitarian organisations have started to align the theories of change of
their interventions with ‘systems thinking’.

A theory of change (ToC) is a specific and measurable description

of an initiative that forms the basis for strategic planning, ongoing
decision-making, and evaluation. It requires participants to clearly
articulate long-term goals, define measurable indicators of success, and
identify what actions are needed to achieve the goals. A well-developed
ToC can help a systems engineer understand how to deliver a successful
solution, and to acknowledge underlying assumptions as well as the risks
therein. Ultimately, a ToC should be plausible, feasible and testable, in order
to serve as a framework for implementing a new system. (Center for Theory
of Change, 2020)

Chapter 2 – Systems engineering-based design process 39

 Establishing a clear ToC before beginning to design a new IM system is
fundamental to the ultimate success of that system, since:

‘Every program [and project] is based on a “theory of change”

– a set of assumptions, risks and external factors that describes
how and why the program [or project] is intended to work.
This theory connects the program’s [or project’s] activities with
its [expected ultimate outcome]. It is inherent in the program
[or project] design and is often based on knowledge and
experience of the program [or project design team], research,
evaluations, best practices and lessons learned.’ (Global Affairs
Canada, 2016)

Consider the approach illustrated below within the context of your IM

project:

What is the Who is What is your What steps What is the What are What is the
problem you your key entry point are needed measurable the wider long-term
are trying to audience? to reaching to bring effect of benefits of change you
solve? your key about your work? your work? see as your
audience? change? goal?

measurable wider
effect? benefits?

START measurable wider

HERE effect? benefits?

key key key key key key stakeholders

assumptions assumptions assumptions assumptions assumptions assumptions

Figure 2.1 – Defining a theory of change (Nesta DIY Toolkit 2014)2

2 [Link] (Retrieved July 15, 2020)

40 Chapter 2 – Systems engineering-based design process

With other members of your project team, start on the left side of the figure
by defining the problem(s) that your IM system must solve. Then, identify
the key stakeholders (users, beneficiaries, administrators, supporters) of the
system, as well as the way that diverse stakeholders will interface with the
system. You can do this at a high level for your ToC, and then very precisely
in your system requirements definition (Section 2.5). Continuing to work
from left to right, identify the progress indicators that will define success
for your system, and establish the wider benefits and long-term impact that
is envisioned. At every step, take note of key assumptions and how they
might create risk or opportunities for your project.

Critical elements of such a process include making sure that the right
stakeholders are in the conversation, that there is active participation, and
that there is space to draft, iterate and refine ideas. These results should
then be converted into a concise, written document that clearly states the
following for your project:

1. Outcomes (situated along causal pathways).

2. Interventions (or activities), that will achieve the Outcomes.

3. Assumptions, which underly any element of your ToC.

4. Rationales, explaining why the interventions will be

impactful.

5. Indicators, to measure your success in a S.M.A.R.T.3 manner.

6. Narrative, to provide context and additional explanatory

detail to your ToC diagrams.

The ToC document should then be reviewed by all project stakeholders,

to confirm common understanding and agreement of the project before a
detailed system design is attempted.

Finally, your ToC is the foundation of a results-based management (RBM)

framework, which has emerged as the preferred approach for managing
donor-funded initiatives. RBM promotes realistic, measurable, and impactful
outcomes over the entire project life cycle.

3 S.M.A.R.T. = Specific, Measurable, Attainable, Relevant & Time-bound.

Chapter 2 – Systems engineering-based design process 41

 Logical framework analysis (LFA, or logframe): it is possible that a logical
framework has already been developed for your project. Logframes employ
a well-established implementation theory, but they can lack an underlying
theory of change. A ToC begins with a participatory and inclusive process
to clearly define desired outcomes, by first working out programme goals
or desired impact and then working backwards on outcome pathways.
Instead of a conventional forward-oriented, reasoned ‘so that’ argument
(e.g. donors should fund a new system so that a humanitarian organisation
can gather field information more efficiently so that analysts can identify
trends in a conflict so that diplomats are better informed so that peace
agreements are enforced), a ToC, by contrast, begins with a long-term goal
and outcomes and then works backwards (in time) to the earliest changes
that need to occur. Only when the pathway has been developed is it time
to consider which interventions will best produce the outcomes in the
pathway (this avoids the classic error of selecting an IM system or software
solution before completing a functional requirements analysis).

B. SYSTEMS ENGINEERING PROCESSES

The technical and management processes that enable systems engineering

to be so effective are summarised in the figure and table below. In general,
these processes aim to ensure a system’s requirements are developed
according to well-defined needs, and that the system remains effective
throughout its design lifetime. These classical processes resemble the
sequential approach that is now commonly referred to as waterfall
methodology, in contrast to a more iterative approach referred to as agile
methodology (see Section 1.7 for a comparison of their advantages and
disadvantages). The SE ‘V’ diagram, which is associated with the waterfall
methodology, is often used to depict the key processes from the planning &
monitoring phase to the disposal phase.

42 Chapter 2 – Systems engineering-based design process

 Initiation Retirement

e
as
Co

Ph
Step 1 Planning / Step 11 Decommissioning

ns

s
Monitoring Framework

ion
ult
Step 10 Maintenance

at

at
er
ion
Step 2 Stakeholder Step 9 Operations

Op
Requirements Analysis

Ph
as
e
Step 3 Concept of Final Acceptance Test
Operations & System Handover
Was the correct

e
system developed?

as
Step 4 Functional

Ph
Step 8 Validation
Requirements Development De

g
Was the system

rin
Full Implementation
s
ign

ito
developed Initial Acceptance Test
Ph

on
correctly? & Transition
as

M
Step 5 System
e

Step 7 Verification
Requirements Development

Integration, Initial Training

& Documentation

Step 6 Implementation

Figure 2.2 – Systems engineering process, the SE 'V' diagram

Table 2.1 – Step-by-step summary of SE processes

NAME OF PROCESS RESULT / DESCRIPTION

Theory of change and results-based monitoring

Planning &
framework (see Section 2.1A above), co-developed
Step 1 monitoring
with and accepted by key stakeholders, to guide the
process
systems design and implementation.

Stakeholder Comprehensive set of use cases (see Section 2.2

consultation & below), which describe the specific functional needs
Step 2
user requirements of each user group in non-technical, user-oriented
analysis language.

Concept of operations (see Section 2.3 below),

based on high-level organisational requirements, to
Enterprise-level
Step 3 describe how the various subsystems of a system
ConOps process
will work to achieve the desired results, and how
various stakeholders will interact with the system.

Chapter 2 – Systems engineering-based design process 43

 NAME OF PROCESS RESULT / DESCRIPTION

FRD documentation (see Section 2.4 below),

developed by the project team, which describes the
Functional
system in a technologically agnostic manner. FRD
requirements
Step 4 should provide hardware and software vendors,
definition (FRD)
and system integrators, with a clear picture of
process
organisational needs so that they can propose their
solutions.

SRD documentation (see Section 2.5 below),

developed by the project team, which technically
defines the system criteria needed to satisfy the
functional requirements of each user group. SRD
System should also include a monitoring plan and an
requirements acquisition & operation budget.
Step 5
definition (SRD)
process

Developed by the project team, in consultation with

subject-matter specialists as well as commercial /
non-commercial solution providers.

Configuration of the selected system architecture in

Implementation
accordance with the SRD, by the project team, as
Step 6 & integration
well as initial training, system-user documentation,
process
and setting of baseline metrics for monitoring plan.

Initial acceptance test which provides objective

Verification evidence that each system element fulfils its
Step 7
process specified system requirements (according to the
measures of performance criteria).

Final acceptance test, which provides objective

evidence that the system, after sufficient test
Step 8 Validation process usage (qualification period), fulfils all stakeholder
requirements specified in the concept of operations
(according to the measures of effectiveness criteria).

Step 9 Operation process Full-scale deployment and adoption of the system.

Sustained performance of the system through

Maintenance installation of software updates, replacement /
Step 10
process upgrade of hardware, retraining of users, updating
of documentation, etc.

Safe retirement of the system at the end of its

Decommissioning life, either through redeployment into a different
Step 11
process environment, or demobilisation (secure archive and
equipment disposal).

44 Chapter 2 – Systems engineering-based design process

Following the step-by-step approach described above will ensure you
design, deploy, and operate an effective system. For a more robust
discussion about each of these processes, consult the sections indicated, as
well as the INCOSE Systems Engineering Handbook. (International Council
on Systems Engineering, 2015)

C. PROJECT TEAM COMPOSITION

The capacity to implement the aforementioned SE technical and managerial

processes comes from the project team. It is important to aim for diverse
representation in the team, and although every project will have a unique
team composition, there are certain roles and responsibilities that are
common in almost every project. The following table summarises the
inactive and active players in most humanitarian information management
system projects – of course, one person may serve in more than one role,
and larger projects will justify more team members than smaller projects.

RESPONSIBILITIES /
ROLE NOTES
ACCOUNTABILITY

The person responsible

The sponsor (e.g. donor, grants
for committing funding
officer, finance director) is a key
Sponsor and resources to a project
stakeholder, but not an active
to meet specific strategic
member of the project team.
objectives.

The sponsor may be supported by

The person responsible a more technical manager to assist
Programme
for initiating, evolving, and with fund administration, monitoring
manager
closing projects. and evaluation. May be an active
inactive

member of the team.

Composed of a chairperson and

managers from Operations, IT,
The senior managers of
Communications, HR, Admin /
the host organisation
Finance, and other relevant units
responsible for enabling
Steering from within the host organisation
the project team, ensuring
committee (SC) (and, optionally, external
policy compliance, and
stakeholders). Most SC members
promoting adoption of the
will not be active members of the
new system.
project team, but essential to its
success.

Chapter 2 – Systems engineering-based design process 45

 RESPONSIBILITIES /
ROLE NOTES
ACCOUNTABILITY

The person responsible

for (1) planning, assessing
and controlling the project,
Combines the SE roles of systems
(2) obtaining a product
Project lead engineer, project manager and
or service in accordance
requirements manager, and is
with the organisation’s
accountable for overall project
requirements, and (3)
success.
eliciting, defining and
analysing the stakeholder
and system requirements.

The person responsible

for defining and analysing
the system architecture, Can also combine the SE roles
Solution
and for planning, of configuration manager and
designer
procuring, and leading procurement manager.
the configuration of
management activities.

The person responsible for

active

Monitoring planning and leading the Combines the roles of verification

specialist verification and then the lead and validation lead.
validation activities.

The person(s) responsible

for ensuring that the
organisation is provided
Typically, one or two infrastructure
with the necessary
Infrastructure managers from the host
facilities, tools, and
manager(s) organisation’s IT, IM/GIS, and/or
communications and
Operations units.
information technology
assets consistent with
business needs.

Technical specialists who are

assigned tasks by the project lead,
The persons authorised
solution designer, monitoring
Implementation to implement the project
specialist, and infrastructure
team members under the direction of the
manager(s). Examples include
other team members.
GIS officers, IT specialists, project
support officers, etc.

Adapted from Guide to SEPM Roles and Responsibilities

(INCOSE UK & APM, 2017)

Consider these various core roles and responsibilities when building your
project team, and if necessary, modify the team’s composition based on
the complexity of your proposed system. Finally, recognise the importance
of establishing some form of project governance, such as a steering
committee, at the earliest stages. In addition to ensuring broad institutional

46 Chapter 2 – Systems engineering-based design process

ownership, a well-structured form of governance will help the team
navigate the various challenges that are inherent in deploying their system
and empower the project lead to be as successful as possible.

D. EMPLOYING CRITICAL PATH & GANTT CHART

ANALYSES

Critical path and Gantt chart analyses will help promote the completion of
your project on time, on budget and within scope (of importance, since
some project managers argue that any increase in one of these factors will
invariably affect the other two, the so-called triple constraint theory). Both
are standard tools in the project management toolkit and although they can
be done manually, consider using a software package like Microsoft Project
or OpenProject for instance, to develop your work breakdown structure
(WBS) (such as tasks, sub-tasks, scheduling, resource allocations), and to
track and report your progress once you get started.

Critical path analysis is a modelling technique that uses the following values
to calculate the longest path to the end of a project:

1. A list of all tasks and sub-tasks required to complete the

project;

2. The time (in days or weeks) that each sub-task will take to
complete;

3. The dependencies between the tasks and sub-tasks; and

4. Logical end points such as milestones or project deliverables.

Chapter 2 – Systems engineering-based design process 47

 Mapping out these values also provides an indication of the earliest and
latest that each activity can start and finish without making the project
longer; it then becomes clear what tasks are ‘critical’ (i.e. on the longest
path) and which have ‘total float’ (i.e. can be delayed without making the
project longer).

Gantt chart analysis provides a visual representation of tasks over time,

as well as their interdependencies. Tasks are shaded in proportion to the
degree of their completion, so a task that is 25% completed is one-quarter
shaded. Resources can also be linked to each task in project management
software, creating powerful analytical, planning and reporting options for
the project team.

The figure below illustrates the combined use of these two forms of project
analysis. Note how the critical path links those tasks in the Gantt chart that
determine the duration of the project (from the GICHD’s Work Plan (as of
June 2020) for the Enterprise GIS project in Ukraine):

Figure 2.3 – Example of a simplified SE-based work plan (OSCE SMM 2020)

48 Chapter 2 – Systems engineering-based design process

E. MANAGING PROJECT RISK

One of the most critical functions of the project team is to manage risk,
and to have contingency plans to mitigate the impact of various threats
to its success. While there are various approaches to assessing risk and
developing such plans, the overall goal should be to be as proactive as
possible, by:

• Questioning planning assumptions by continuously asking

‘what if <scenario> happens?’;
• Constantly anticipating the impact of external events on the
project, and having a plan to respond;
• Informing other stakeholders of identified risks and response
plans, so that their expectations are realistic and calibrated;
• Establishing a team culture that promotes risk consciousness;
• Mitigating the impact of external dependencies on system
implementation, so that even if the project team has limited
ability to control them, these external dependencies have a
minimal effect on the team’s plan;
• Developing formal and informal contingency plans for all
significant risk, including:
◦ Procurement delays;
◦ System failure and cyberattack;
◦ Community lockdown / inability to come on-site;
◦ Staff turnover / capacity constraints;
◦ Delays that affect the float or critical path of your
project (see Section 2.1D);
◦ Funding shortfalls;
◦ Changing user needs and requirements;

• Other organisational-specific approaches as appropriate.

While every member of the project team should be involved in managing

uncertainty, it is the ultimate responsibility of the project lead to ensure
that strategic, technical, financial, administrative, political, environmental,
and human risk is constantly monitored and, whenever possible, mitigated
through effective contingency planning and decision-making.

Chapter 2 – Systems engineering-based design process 49

 The project lead should constantly consider when and how to engage other
stakeholders effectively in managing risk and in making decisions, and
remember that there are typically four types of decisions: (1) unconscious
decisions, (2) conscious decisions needing a quick answer, (3) conscious
decisions needing a more extensive answer, and (4) extensive decisions
needing full stakeholder participation. (SE-Training, 2020)

50 Chapter 2 – Systems engineering-based design process

2.2 STAKEHOLDER
CONSULTATION / USER
REQUIREMENTS ANALYSIS
Even when the need for a new or improved IM system is obvious, it is
important to invest the time in consulting the stakeholders of that system,
to understand their needs and concerns. This is also an essential part of
building a sense of ownership, or buy-in, for them to the proposed system
when it is implemented.

As a first step, the process begins with mapping out all the various
stakeholders inside and outside the host organisation. External stakeholders,
such as donors, beneficiaries, and partner institutions, should also be
identified and prioritised as part of this process.

Typically, a user requirements analysis involves a series of consultations,

composed of presentations, brainstorming sessions, and open discussions
across the spectrum of stakeholders. These consultations may be with
individuals, small teams, or large groups, and are intended to inform
the system requirements. Use cases define the individual functional
requirements of the proposed system, and a sophisticated system may
have dozens of unique use cases that represent the full scale of capability
expected from the system.

The figure below shows an example of a use case worksheet for the
GICHD’s Enterprise GIS (EGIS) project in Ukraine. This worksheet defines
the basic requirements for one specific functionality needed by the
organisations’s image analysts and was one of nearly 70 use cases prepared
during the consultation process. A blank template of this worksheet can be
downloaded from the following SE guide’s resource website, at: https://
[Link]/en/seguide/

Chapter 2 – Systems engineering-based design process 51

 Figure 2.4 – Example of a use case worksheet (OSCE SMM 2019)

Once all user requirements are documented as specific use cases, they are
reviewed and approved by relevant stakeholders and then used to define
the functionality of the proposed system. Chapter 4 of the guide describes
the EGIS project in more detail, together with several other case studies
featuring SE-based design.

52 Chapter 2 – Systems engineering-based design process

INFORMATION MANAGEMENT SYSTEM FOR MINE
ACTION (IMSMA)
Stakeholder consultations have shaped the development of the latest
generation of IMSMA – IMSMA Core – and guided the design of everything
from the underlying data schema to its various forms and dashboards.

The importance of stakeholder consultations continues each time IMSMA

Core is deployed to a new organisation. Early in the deployment process, it
is advisable to organise a stakeholder workshop. This is ideally a one-week
gathering of representatives from the national mine action centre (NMAC)
and other stakeholders, to determine the IM needs, requirements, and
priorities. In addition, it is an opportunity to identify areas for improvement
and standardisation which stakeholders can agree upon. To begin this
process, first identify the broad range of stakeholders that need to be
consulted. For example, an overseas donor might be interested in the
number of square metres of cleared land, whereas a local NGO working in
explosive ordnance risk education (EORE) might need information tools to
prioritise and assess EORE activities.

At least one capable representative should be identified from each

stakeholder organisation, through a process referred to as stakeholder
mapping. This process identifies entities that are part of the mine action
programmes and other relevant humanitarian / development actors, that
represent those who use IM or could benefit from IM products supported
by the NMAC. With each identified stakeholder organisation, map out their
activities and identify candidates to represent each of them.

Chapter 2 – Systems engineering-based design process 53

 Encouraging diverse representation in terms of who is consulted will help
ensure that different perspectives on information requirements are reflected.
Those who conduct the work will always know in more detail what the
processes and workflows are, and how these relate to their information
needs and requirements. Examples of workflows and roles include:

• EORE – educators, coordinators, head of programme;

• Victim assistance – medical staff, field teams, coordinators,

head of programme;

• Implementing partners – IM, field operators, coordinators;

• Donors – country liaison;

• Decision makers – government officials, NMAC officials,

community leaders.

Identification and review of potential stakeholder representatives must

occur in cooperation and active participation with the NMAC. Take note of
and be sensitive to the cultural hierarchy in which you will be working.

Stakeholder pre-assessment
Once stakeholders are identified, prepare a questionnaire for them to fill out.
This will offer a guide for them on what will be discussed in the workshop,
as well as provide an initial understanding of stakeholder expectations. This
pre-assessment must be done by all stakeholder representatives. Some may
prefer to have different questionnaires for different stakeholders, such as
technical, operations, and management. With IMSMA Core deployments it
has been found to be effective to use a generic set of questions that serve
to open dialogue and guide further conversations.

54 Chapter 2 – Systems engineering-based design process

Suggested questions for a pre-assessment:

1. What are five key things you need information on to conduct

your activities?

2. Are you currently able to get information on these five key

things?

3. Do you currently use information / data provided by the IM

service of the NMAC? If yes, check the items below:
◦ Maps
◦ Statistics
◦ Information dashboards
◦ Reports
◦ Other (elaborate)

4. Where in your operations are these information / data

products used?
◦ How frequently are they used?
◦ Are you able to easily access these when needed?
◦ Is enough information provided? If no, what
should be added?

5. What would you suggest could be improved?

6. On a scale of 1 (low confidence) to 5 (high confidence) what
is your level of confidence in the quality of data?

7. Do you / your organisation currently submit data to the

NMAC?
◦ If yes: on a scale of 1 (inefficient) to 5 (efficient),
how efficient is the data submission process?

8. Do you use survey forms provided by the NMAC? If yes,

which survey forms do you use?

9. Do you conduct field data collection on mine action

activities? If yes, please describe.

Chapter 2 – Systems engineering-based design process 55

 A. Gathering user requirements

Presentations
Prior to the workshop, advise each stakeholder that they will be invited to
present their current, as well as proposed, way of working with information,
and with the NMAC. This is an opportunity for them to show what their IM
needs and requirements are, as well as what they hope the new IM system
will achieve for them. Suggest they structure their presentation to include:

• Introduction of their organisation;

• Ongoing activities (including who is conducting IM in country

and how);

• How data is submitted to the NMAC;

• How information / data is retrieved from the NMAC;

• Needs / requirements of stakeholders and the NMAC.

Together with the stakeholders, identify the users / roles within their
organisation. In some cases, this will need to be done in collaboration with
the NMAC. As the NMAC is typically the primary client for whom IMSMA
is being deployed, make sure to always consult with them before any
independent outreach to stakeholder groups.

User stories
In the stakeholder workshop, ask participants to identify types of
users and each user’s needs as part of an exercise. This will engage the
stakeholders and encourage them to think in the framework of identifying
and understanding users and their requirements. See an example of an
exercise prompt for user roles / needs below. Throughout this engagement
it is important to keep in mind the needs of related areas / sectors such
as education, protection, health, and others. At the stage of defining user
stories, it is again important to be sure applicable groups have a voice
among the stakeholders.

56 Chapter 2 – Systems engineering-based design process

Workflows and processes
In the stakeholder workshop, the exercise on workflows and process
mapping will be key in showing stakeholders what information you will
need from them. For this exercise, introduce stakeholders to the principles
of process mapping and conduct a group exercise creating process maps
of workflows for various activities in mine action relating to data and
information.

An oval shows the input to

start a process or the output at
the end of the process Arrows show
the direction
of flow of the
process
A box or rectangle
shows a task or activity
performed in the process

Diamonds show
where a decision is
required or where
there is a yes/no Feedback
question loops should
be closed
YES
taking you
back to or
onwards to
There is usually only one
another step
arrow out of an activity NO

box: if there are more

you may need a decision
diamond

An oval shows the Input to

start a process or the output at
the end of the process

Example of an introduction to process mapping visualisation

Chapter 2 – Systems engineering-based design process 57

 It is recommended to divide stakeholders into their user / role groups. For
example, all EORE stakeholders in one group, land clearance operators
in another. The best approach is to have them create a minimum of three
process maps for three different roles within their thematic group. If
time allows, ask these groups to continue making process maps for all
users / roles in their focused theme. Continue to move through the groups,
observing their progress and providing direction and clarification as needed.
Remember, what they produce is what will guide your design approach.
Ensure they are providing you with all the information you need during this
process.

After the workshop is completed, request that stakeholder organisations

(who submit data to, or use data from the NMAC) provide process maps
or workflows specific to their organisation on where data is: data used
from the NMAC (including forms), and data collected and submitted to the
NMAC.

[Note: Work directly with a stakeholder organisation to get a clear mapping

of their workflows and processes.]

B. Lead user engagement

It is important to keep stakeholders involved in the development process

to gain their feedback and monitor whether solutions being developed are
effectively addressing user needs and requirements.

Identify a lead user (or focal point):

• Identify focal points within each stakeholder organisation.
Discuss with the stakeholder organisation who their lead user
will be;

• Maintain regular contact with the lead user and ensure their
satisfaction with the system requirements by providing
regular updates on development progress and seeking their
feedback.

58 Chapter 2 – Systems engineering-based design process

IMSMA Core progress meeting:
• Hold a regular progress meeting with stakeholders and the
NMAC;

• Review progress on development;

• Discuss road map / timeline of project;

• Any potential delays should be made clear to stakeholders in

these meetings;

• Discuss stakeholders’ feedback and / or concerns.

Chapter 2 – Systems engineering-based design process 59

 2.3 CONCEPT OF OPERATIONS
The completion of the stakeholder consultations and use cases should
permit the development of a conceptual view of a proposed system. At a
minimum, this includes a high-level block diagram showing the functional
elements (or subsystems) that must be integrated, in order to achieve a
set of clearly defined performance requirements or objectives, supported
by sufficient narrative to enable the reader to clearly conceptualise the key
elements of the system.

A concept of operations (ConOps) ‘is a user-oriented document

that describes systems characteristics for a proposed system
from a user’s perspective. A CONOPS also describes the
user organization, mission, and objectives from an integrated
systems point of view and is used to communicate overall
quantitative and qualitative system characteristics to
stakeholders.’ (IEEE, 1998)

A ConOps ‘describes the overall high-level concept of how the

system will be used to meet stakeholder expectations, usually
in a time sequenced manner. It describes the system from an
operational perspective and helps facilitate an understanding
of the system goals. It stimulates the development of the
requirements and architecture related to the user elements
of the system. It serves as the basis for subsequent definition
documents and provides the foundation for the long-range
operational planning activities.’ (NASA, 2016)

The ConOps is needed in order to obtain preliminary consensus amongst

all the stakeholders before committing to detailed systems design. In other
words, it precedes – and once approved, it shapes – the development of
the SRD. The SRD provides a comprehensive, technical explanation of a
system based on user requirements which are identified during stakeholder
consultations and represented by the concept of operations.

60 Chapter 2 – Systems engineering-based design process

The process of defining use cases helps to describe stakeholder
expectations. The ConOps should therefore include specific measures
of effectiveness (MOEs), that can be employed to ensure satisfactory
achievement of stakeholder expectations during the validation stage of
system delivery.

MOEs are the measures of success designed to ‘correspond to accom­

plishment of the system objectives as defined by the stakeholder’s
expectations. They are stated from the stakeholder’s point of view and
represent criteria that are to be met in order for the stakeholder to consider
the project successful. As such, they can be synon­ymous with mission /
project success criteria’. (NASA, 2016)

MoEs should also provide a results-based monitoring framework to assess

the longer-term impact of any system. The need to baseline and monitor
progress through indicators linked to outcomes and goals linked to a theory
of change is essential, to provide an onwards diagnostic on implementation
issues as well as providing evidence of the benefits of the investment in
due course. Being able to demonstrate that more effective decisions
taken, based on the improved system, saved time, money or lives, is highly
relevant to senior managers, donors and others.

As illustrated in the figure below, the translation of user requirements into

functional requirements, and then into the final design solution, is iterative
– the project team must be willing to periodically test their progress against
the ConOps (and if necessary, specific use cases) to ensure the final design
of its system fulfils all of the criteria for success defined by its stakeholders.

Chapter 2 – Systems engineering-based design process 61

 Iterate ConOps Iterate Requirements
Iterate
Expecta�ons
Stakeholder Expecta�ons Requirements Defini�on
Inconsistencies - Iterate
Needs, No - Iterate
Goals and
Derived and
Objec�ves
Allocated
Requirements
Program Develop Good Yes
Constraints • Func�onal Validate Req. Meet
Authority ConOps • Performance Req. Set ConOps?
• Interface
• Opera�onal
Success • Safety
Criteria • “ili�es”

Design Solu�on Defini�on Logical

No – Recursive Cycle Iterate
Decomposi�on

Decomposi�on
Success
To Product Criteria Develop
Lowest Develop • Func�onal Flow
Realiza�on Design
Level? Architecture • Temporal Flow
Processes
• Behavioral
• Data Flow
• States and Modes
Evaluate Compare
ConOps

Figure 2.5 – Interrelationships between system design processes

(NASA, 2016)

Once the ConOps has been reviewed and accepted by the stakeholders
of a new system, the project team can proceed with the development
of the functional requirements of that system, and then with the system
architecture. At each step, the ConOps is consulted to ensure the ultimate
design will meet user needs.

There are examples of how to draw a ConOps system diagram in the EGIS
and SIATA case studies found in Section 4. These diagrams, combined with
a short description of how each of the subsystems are expected to work,
are sufficient to transition to the next stage of the SE design process – the
functional requirements analysis.

62 Chapter 2 – Systems engineering-based design process

2.4 FUNCTIONAL
REQUIREMENTS ANALYSIS
In order to translate a ConOps into system requirements, an intermediate
step – functional requirements analysis (FRA) – is employed to describe the
system requirements from the host organisation’s perspective. The FRA is a
detailed, function-by-function description of how the system will ultimately
satisfy its user requirements.

Ideally, the FRA should avoid favouring specific hardware and software
solutions, and be as ambivalent to specific technologies as possible.
For example, if an organisation requires a certain type of dashboard to
be accessible to a group of users, the FRA should describe as clearly as
possible the data, analysis and display formatting of the dashboard, and
avoid referring to a specific commercial off-the-shelf (COTS) / software-as-
a-Service (SaaS) solution that might bias or constrain the potential ways to
achieve these functional requirements.

BENEFITS OF WELL-WRITTEN REQUIREMENTS

In the stressful, dynamic reality of almost any humanitarian emergency,

following system design processes like FRA might seem like a luxury when
people’s lives are at risk. A hastily deployed IM system might be easier to
justify than a properly-deployed system that takes more time to design and
implement.

Employ a pragmatic approach, and balance good practices with the

realities on the ground. When a proposed IM system involves significant
user expectation and / or cost, there needs to be an equally significant
commitment to ensuring its design will meet those expectations.
When a system involves little investment and low user expectation, a
correspondingly lower commitment to its design may be defensible.

Chapter 2 – Systems engineering-based design process 63

 For mission-critical IM systems, the effort invested in preparing well-written
design requirements will reduce technical and financial risk and will improve
the likelihood that user needs will be met. Such a system will be more
effective, durable, and successful, and will be cheaper and less prone to
delays. Most importantly, once deployed, this system is more likely
to be employed and supported by various stakeholders, since they
will have been given the opportunity to contribute to its design.

Benefit Rationale
Establish the basis for The complete description of the functions to be performed by the product specified in
agreement between the the requirements will assist the potential users in determining if the product specified
stakeholders and the meets their needs or how the product should be modified to meet their needs. During
developers on what the system design, requirements are allocated to subsystems (e.g., hardware, software,
product is to do and other major components of the system), people, or processes.

Reduce the development The Technical Requirements Definition Process activities force the relevant
effort because less rework stakeholders to rigorously consider all of the requirements before design begins.
is required to address Careful review of the requirements can reveal omissions, misunderstandings, and
poorly written, missing, inconsistencies early in the development cycle when these problems are easier to
and misunderstood correct thereby reducing costly redesign, remanufacture, recoding, and retesting in
requirements later life cycle phases.

Provide a basis for The description of the product to be developed as given in the requirements is a
estimating costs and realistic basis for estimating project costs and can be used to evaluate bids or price
schedules estimates.

Provide a baseline for Organizations can develop their verification and validation plans much more
verification and validation productively from a good requirements document. Both system and subsystem
test plans and procedures are generated from the requirements. As part of the
development, the requirements document provides a baseline against which
compliance can be measured. The requirements are also used to provide the
stakeholders with a basis for acceptance of the system.

Facilitate transfer The requirements make it easier to transfer the product. Stakeholders thus find it
easier to transfer the product to other parts of their organization, and developers find it
easier to transfer it to new stakeholders or reuse it.

Serve as a basis for The requirements serve as a basis for later enhancement or alteration of the finished
enhancement product.

Figure 2.6 – Benefits of well-written requirements (NASA, 2016)

The table above summarises the principal arguments in favour of

formal SRD documentation. The development of this documentation
includes a thorough analysis of system requirements, which begins with
understanding its functional, physical and operational views.

64 Chapter 2 – Systems engineering-based design process

A. UNDERSTANDING FUNCTIONAL, PHYSICAL AND
OPERATIONAL VIEWS

The SE design process begins with the development of a ConOps, and

then the decomposition of that system conceptualisation into functional,
physical, and operational views. The functional view describes what
the system must do to produce the required operational behaviour. It is
exclusively motivated by user requirements, and not the availability of
any potential commercial solutions; in fact, it should be agnostic of such
solutions. This way, the functional requirements (in combination with the
physical requirements shown below) serve as the primary determinant of
the final system specifications. Functional view information includes:

1. System functions;
2. System performance:
a. Qualitative (how well it performs, measured
through user feedback and reported levels of
satisfaction);

b. Quantitative (how much it can perform, measured

through system analytics);

c. Timeliness (how often it can perform as expected,

measured through availability metrics);

3. Tasks or actions to be performed;

4. Inter-functional relationships;
5. Hardware and software functional relationships;
6. Performance constraints (e.g. field workers without mobile
data access, or unable to safely use certain technologies in
active conflict zones);
7. Interface requirements including identification of potential
open-system opportunities (potential standards that could
promote open systems should be identified);
8. Unique (i.e. function-specific) hardware or software; and
9. Verification and validation requirements (see Section 3.6).

Chapter 2 – Systems engineering-based design process 65

 Once the ConOps has been used to derive the functional view of a new
system, the project team can begin to decompose it into a physical view,
to focus on how the system will be constructed. This will also define the
physical interfaces between various users and equipment, and technology
requirements. Physical view information would normally include:

1. Configuration of system:
a. Interface descriptions;

b. Characteristics of information displays and

operator controls;

c. Relationships of operators to system / physical

equipment; and

d. Operator skills and levels required to perform

assigned functions.

2. Characterisation of users:
a. Handicaps (special operating environments); and

b. Constraints (movement or visual limitations).

3. System physical limitations:

a. Physical limitations (capacity, power, size, weight,
etc.);

b. Technology limitations (internet bandwidth, power

requirements, language, etc.);

c. Database models and archives;

d. Existing and legacy systems;

e. Custom vs commercial-off-the-shelf requirements;

f. Reusability and disposal requirements; and

g. Legal or institutional policies / standards.

66 Chapter 2 – Systems engineering-based design process

Finally, the project team must consider the system’s operational view,
or what it will allow its users to do, and how. This is not the same as the
concept of operations, and is better understood instead as an operational
concept, since it includes:

1. Operational needs definition;

2. System mission analysis;

3. Operational sequences;

4. Operational environments;

5. Conditions / events to which a system must respond;

6. Operational constraints on the system;

7. Mission performance requirements;

8. User and maintainer roles (defined by job tasks and skills

requirements or constraints);

9. Structure of the organisation that will operate, support and

maintain the system; and

10. Operational interfaces with other systems.

Adapted from (US DoD, 2001)

As shown in the figure below, the iterative decomposition of the user

requirements into functional, physical and operational views also involves
consideration of interfaces, or the boundaries between various internal and
external elements that when working together create the desired system.

Chapter 2 – Systems engineering-based design process 67

 ViewPoints
A2 Operational Analysis
A3 What the users of
the system need to
Need understanding

A1

accomplish

F2 F4 Reqs
Functional &
Non Functional Need
F5

F1 F3
What the system has to
ViewPoints accomplish for the users
A : Operational activity F22
F21
F : Function
C : Component
C2
F6
F1
F3
Logical Architecture
Solution architectural design

C1
C3 How the system will work
ViewPoints
WRIXOĆOOH[SHFWDWLRQV

F21 F22
C2
F6 C12

F1

C11 C1’
F7
C3
C4
Physical Architecture
How the system will be
Buses Processors
developed and built
ViewPoints

Figure 2.7 – Logical decomposition of system conceptualisation (PPI 2020)4

Map out the functional, physical and operational views of your proposed
system before deciding what commercial or open-source solutions are
advisable to prevent design or technology bias; user needs should always
dictate the solutions employed, not the availability of any specific solution.
Indeed, the drafting of the functional requirements should exclude solutions
providers, who should be engaged only once it is time to design the system
requirements (see Section 2.5).

The exception, of course, is when an organisation has already invested in a

particular technology which must be employed to achieve as many of the
functional requirements as possible. This is not ideal but also not unusual,
and the skilled project team will maintain an open mindset when forced to
accommodate an existing technology platform.

4 [Link]

68 Chapter 2 – Systems engineering-based design process

B. DATA & LEGACY SYSTEMS CONSIDERATIONS

You may have noted that existing database and legacy systems are
important physical view considerations if they need to be replaced by – or
connected to – a new system. Almost every organisation must deal with
how to rebuild or migrate their existing capabilities to an upgraded system.
This is an essential activity during the functional requirements design phase,
as it forces the project team to consider important questions such as:

• Should we retain the data model that organises our current

database, or is this the time to re-engineer our data model to
support future IM systems growth?
• Do we need to migrate data archives to the new system’s
database, to permit longitudinal or big data analytics as well
as rapid recovery of historical data?
• Can our current hardware continue to meet the performance
requirements of the new system, should we upgrade our
local infrastructure, or should we move to cloud-based
hosting solutions?
• Are there application programming interfaces for external
systems that need to interface with the new system?
• Can our legacy system meet user requirements without
being replaced? If so, are there other reasons which might
justify replacing it versus retaining it within the new system
architecture?
• Is the legacy data suitable for use in the new system? Does it
pass the fit-for-purpose tests to justify migration of the legacy
data to the new system, or do we need to migrate selected
data records and attributes only?

As you can easily imagine, a careful and comprehensive analysis of all of

an organisation’s relevant databases and legacy systems is a prerequisite
to finalising the functional design of a new system. Your project team
should engage existing users of those databases and systems, as well as
potential solution providers if required, to prevent mistakes, oversights or
false assumptions creating points of failure in the final design of your new
system. Section 3.1 below explores data and legacy systems in further
detail.

Chapter 2 – Systems engineering-based design process 69

 C. PERFORMANCE

To determine the optimum system architecture, it is necessary to clearly

specify its performance targets using a set of measurable, objective
indicators. If performance specifications aren’t defined at the functional
design stage, the project team cannot be certain the system will support
key factors such as:

• Response time (latency, or user wait times for each process

or interaction with the system, at various times of the day);

• Workload (processing time, or throughput, at various periods

of the work cycle);

• Scalability (ability to grow to support usage and technological

advancement over time);

• Availability (percentage on time, or recovery time objective

in case of system failure or breach, where high availability
systems involve additional investment in redundant
infrastructure in order to minimise the risk of system failure);

• Data resilience (acceptable loss of data, or recovery point

objective in the case of a system failure or breach);

• Security (user authentication protocols, authorisation /

accessibility protocols, external and internal threats and
sensitivities, etc.).

These are often referred to as non-functional requirements. Consideration

of both functional and non-functional performance requirements will help
you to define system attributes based on your stakeholder consultations,
and to ensure that system security, reliability, performance, maintainability,
scalability, and usability aren’t overlooked in the design process. For most
organisations, this could result not only in non-compliance with legal
and policy requirements, but unacceptable outcomes once the system is
deployed.

70 Chapter 2 – Systems engineering-based design process

2.5 SYSTEM REQUIREMENTS
DEFINITION
The final step in the design process is to convert the functional requirements
definition into a detailed, technical vision that can be implemented by the
project team. In other words:

The purpose of the System Requirements Definition process

is to transfer the stakeholders, users-oriented view of desired
capabilities into a technical view of a solution that meets the
operational needs of the users. (ISO/IEC/IEEE 15288, 2015)

Up to now in the system design life cycle we intentionally refrained from

discussing specific commercial or open technology solutions. In the system
requirements analysis, we research, compare, select, and decide how to
integrate specific technologies to achieve the stated functional (and non-
functional) requirements. Then, the process of implementation is defined
in a detailed work plan that includes a final budget as well as a clear
assignment of roles and responsibilities. And lastly, the SRD includes the
minimum criteria with which system acceptance will be verified. [Note:
validation is based on the ConOps, but verification is based on the SRD’s
criteria as indicated in table 2.1.]

Although every SRD will be unique, it is helpful to consider the following

points before deciding how your project team should structure its SRD
documents:

• Market analysis – even if the project’s sponsor has identified

a specific type of solution prior to launching the project, it is
still advisable to survey various open-source, COTS and SaaS
options before determining how best to meet the system
requirements. An updated understanding of these options
often increases the confidence that the proposed system
reflects the best possible approach to achieving its defined –
and undefined / future – requirements.

Chapter 2 – Systems engineering-based design process 71

 • Research & development (R&D) considerations – although it
is unlikely that a significant amount of R&D will be feasible
in the context of an urgent humanitarian IM systems
deployment, take a moment to identify opportunities or
challenges that may justify such an effort, either internally or
by a partner institution that specialises in the area(s) of the
proposed R&D.

• Cost analysis – system budgeting should include

procurement, operational costs including maintenance of
software, hardware, communication services and databases.
Cost analysis should also include initial and ongoing user
training, security, continuity of operations, and contingencies.

• Verification criteria – while the measures of effectiveness

define the criteria for meeting stakeholder expectations, and
were included in the ConOps, measures of performance
(MOPs) define a system’s operational performance
requirements. MOPs are derived from the MOEs, and
reflect the technical, quantifiable, and measurable system
characteristics deemed necessary to achieve the more
qualitative MOEs (NASA, 2016).

• Data management – for most humanitarian organisations,

the collection, storage, maintenance, and access of data in
a secure, efficient, and reliable manner is a core challenge,
and a primary objective of adopting a new IM system.
The SRD should address this matter thoroughly. Data
modelling, archive migration, metadata (information about
each data file), and data recovery / resilience are essential
considerations in any new IM system design.

• Subsystem approach – a well-structured SRD will describe

a complex system architecture using the system of
systems model proposed by the ConOps. The technologies
and integration of various subsystems (data generation,
storage / management, analysis, display, communications /
reporting, etc.) can still be used to ensure that the SRD is a
useful, navigable document. The reduction of systems into
subsystems helps to simplify and explain how a broader
vision will be achieved, on time, on budget and within scope.

72 Chapter 2 – Systems engineering-based design process

 • Partner engagement – the functional requirements definition
is intended to communicate the operational what of a
system, and the SRD should provide the technical how,
when and how much of that system. Very few humanitarian
organisations have the internal expertise to develop their SRD
without engaging system integrators, equipment suppliers
and other external service providers. These partners may be
selected because of historical relationships, trusted referrals,
commercial marketing or open bids (request for proposals).

• Tasking and scheduling – each activity can be broken down

into tasks, or work packages. These are basic elements in
the WBS that show the hierarchical order of work needed
to complete the system. This chronological approach to
developing the WBS guides the development of the cost
breakdown structure, which identifies the cost for each stage
of the system life cycle. Collectively, the project management
professional completes these activities in order to understand
the life cycle cost of the system, and to schedule associated
resources.

The approach described in this section may seem overwhelming or even

excessive to some readers. You may have thought, ‘We’re not launching
rockets into outer space or developing a nuclear power station, we just need
a better way of managing our information, and we need it now!’ The level
of investment in the design and planning of a project is always contextual,
and every organisation needs to consider its system requirements, given its
realities. Be assured that an effective SRD doesn’t need to be a thousand-
page document – it can be a short, precise document of just a few pages,
particularly for a standard deployment of a COTS / SaaS-based system that
presents little risk or cost for an organisation. It will obviously need to be
more robust for a system of systems involving complex integration of a
wide range of functionality at significant cost. Take the appropriate amount
of time to consider what level of effort should be invested in defining system
requirements before you begin system implementation. The next section
provides some important strategic considerations for implementation.

Chapter 2 – Systems engineering-based design process 73

 REFERENCES
Center for Theory of Change. (2020). FAQs. Retrieved June 23, 2020, from
[Link]

Global Affairs Canada. (2016). Results-Based Management for International

Assistance Programming at Global Affairs Canada: A How-to Guide.
Office of the Deputy Minister of International Development,
International Assistance Operations Bureau. Ottawa: Global Affairs
Canada. Retrieved July 14, 2020: [Link]
world-monde/assets/pdfs/funding-financement/results_based_
management-gestion_axee_resultats-[Link]

IEEE. (1998). IEEE 1362 – Guide for Information Technology - System

Definition - Concept of Operations (ConOps) Document. IEEE.

INCOSE UK & APM. (2017). Guide to SEPM Roles and Responsibilities.

INCOSE UK Ltd. INCOSE & the Association for Project Management.
Retrieved July 14, 2020 from [Link]
[Link]

International Council on Systems Engineering. (2015). INCOSE Systems

Engineering Handbook: A Guide for System Life Cycle Processes and
Activities (4th ed.). (D. D. Walden, G. J. Roedler, K. J. Forsberg, R. D.
Hamelin, & T. M. Shortell, Eds.) San Diego, California, USA: John Wiley
& Sons, Inc.

ISO/IEC/IEEE 15288. (2015). Systems and software engineering — System

life cycle processes ([Link]). Geneva: ISO. Retrieved September 5,
2020 from [Link]

NASA. (2016). NASA Systems Engineering Handbook. Washington, DC:

NASA. Retrieved June 18, 2020 from [Link]
default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf

74 Chapter 2 – Systems engineering-based design process

SE-Training. (2020). Presentation — SE Foundations: Decision & Risk
Management. Geneva: SE-Training GmbH

United States Department of Defense. (2001). Systems Engineering

Fundamentals (1st ed.). (D. S. College, Ed.) Fort Belvoir, Virginia, USA:
Defense Acquisition University Press

Chapter 2 – Systems engineering-based design process 75

 CHAPTER 3 –
IMPLEMENTATION
STRATEGIES

76 Chapter 3 – Implementation strategies

Once the design of a new information management (IM) system has been
approved by stakeholders, it is time to implement the system. In some
cases, a new system will replace one or more existing (legacy) systems and
may therefore require the migration of original data and functionality to the
new system. In other cases, an organisation may have very little existing
data, software, hardware, or processes that are relevant to a new system.

This chapter describes key considerations in data and legacy systems

migration, and then explores the sequence of activities that characterise the
deployment, validation, and delivery of a new system.

3.1 DATA AND LEGACY

SYSTEM MIGRATION
Humanitarians and members of peace missions rely on the use of different
application software to fulfil daily tasks and reporting. These usually include
Word documents, Excel spreadsheets, Outlook emails, Adobe Acrobat files
and readily available software. With access to fast internet connectivity,
organisations can also use cloud-based digital platforms such as Google
Drive and Esri’s ArcGIS Online that allow easy sharing with others and, for
basic use, do not require a complex setup. Medium and large programmes
lean towards using custom-built or configured software, tailored to service
their operational demands, and that standardise workflows.

Technology constantly evolves. Software requires maintenance and

upgrades to keep up with security standards, operating systems, new
hardware, and changes to systems it may interact with. Sometimes,
replacement with a new system is more fitting and cost effective than
maintaining applications and systems built using outdated technologies.

Many organisations cannot update or adapt new systems and the reason
is not only the cost of developing a new system, but the high level of
complexity of migrating historical data to the new system. Data does

Chapter 3 – Implementation strategies 77

 not have a price tag as its use defines its value. Losing data can lead to
noticeable financial and reputational damage for an organisation and means
interruption to its work. That is why it is vital for stakeholders to have full
access to their historical data even when using a new system.

From an information management perspective, we use the term ‘migration’

to describe the moving of data and processes from one locality (system)
to another locality (system) and integrating the historical data in the new
system environment.

The migration process requires a successful transfer of the data,

information, processes, and business logic to the new system. To maintain
accuracy of and credibility in the system, it is critical to ensure that no data
is unintentionally lost or incorrectly changed during this process.

A failure in migration is a failure in new system implementation. Legacy

and new systems should only run in parallel until the migration process
and testing has been completed, after which the legacy system must be
decommissioned and properly backed up in case it needs to be inspected
later.

We can complete a successful migration in a consolidated one-time effort,

or we can divide it into different stages as the development of the system
progresses. Start by migrating parts of the system for certain operational
divisions, as long as it does not affect the whole of the IM system. This will
allow you to start using the migrated components and benefit from the new
system sooner. There are various factors that affect migration, and these
include:

1. Time: system migration is time consuming, regardless of the

system formats and the skilled resources available. Copying
data from one table to another is fast, but the validation of the
data requires a considerable amount of time, and an ill-prepared
migration can hide data issues until much later in the process,
requiring a considerable amount of extra work at later stages.

78 Chapter 3 – Implementation strategies

2. Technical differences: systems generally don’t communicate
well with each other due to the different technology platforms in
use, and thus require regulations or protocols that standardise and
govern the communication process between the systems. Defining
the use cases, or business logic, of the new system allows you to
define test cases for the new system and compare the results with
the old system to ensure a successful data migration, and that the
new system delivers accurate and reliable output.

3. Technical resources: we cannot implement a migration without

having the proper technology and human resources in place. A
system migration requires a lot of technical knowledge of both
the old and the new systems. It requires an understanding of the
functionality, technology components, end user requirements,
testing procedures, etc., and in certain situations requires
advanced programming skills. It is important to collaborate
with experts in your team, project, or peer group and exchange
knowledge and experiences, sharing different solutions, in order to
identify the most effective solution for the migration by having the
right resources in place.

4. Training: during the migration, we will see the first signs of user
acceptance and resistance. Many features designed in the system
will differ from the way it was implemented in the legacy system
due to improvements in end user interface design, technology
changes and even the development of new digital platforms.
This creates what appears as a shift in the business logic when
migrating existing processes to the more efficient new system, as
the implementation of the business logic differs from the legacy
system. Training helps to mitigate user resistance by providing
explanations for the improved implementation of the business
logic and speeds up the adoption process. Resistance to change
is normal behaviour, but by identifying and demonstrating the
reasons for and benefits of the changes, we will lower user
resistance to the adoption of the system; this helps users adapt to
the new processes and to overall acceptance of the new system by
the user. In addition, training increases the level of trust in the new
system by providing users with the knowledge and skills required
to effectively use the new system and by indicating the gaps
existent in the legacy system, and how they are addressed in the
new system.

Chapter 3 – Implementation strategies 79

 5. User validation and acceptance: a new system will either
replicate the legacy system functionality and produce output
faster, or extend the legacy functionality. It is therefore important
to ensure that we confirm that we do not lose functionality or data
in the migration to the new system, unless it is explicitly required
and defined in the system design process. User acceptance testing
is the final step in ensuring that we have developed the users’
skills sufficiently in using the new system effectively and, through
the test cases, ensures that we have covered all the functionality
required of the new system. In a phased approach, we apply the
test cases and user acceptance testing following the migration
of each component to ensure that the new component works
as needed before moving to the next component. The different
components will likely have an impact on each other during the
migration process, so it is wise to conduct a final user validation
and acceptance test to confirm that the migration process has
been completed successfully and that all components interact as
required.

6. Data fitness for purpose: before migrating legacy data to a new

system, consider its fitness for purpose and its quality. Fitness
for purpose is the affordance of data to be interpreted and used
in a context that permits its effective usage. Data quality is the
discrepancy between the fitness for purpose of optimal data versus
actual data – quite simply, how closely the available data resembles
the theoretical ideal of that same data. (Mocnik, Fan, & Zipf, 2017)

There are six dimensions to data fitness:

1. Completeness: the proportion of data that is captured and stored

against the potential of 100%;

2. Correctness: the degree to which the data is ‘true’;

3. Timeliness: the degree to which the data represent reality from a

required point of time;

4. Uniqueness: refers to data that must not lose their unique field
values (such as victim or employee records, village identifiers, etc.);

5. Validity: the degree to which data conform to the required format,

type and range (also known as syntax);

6. Acceptability: the degree to which data is acceptable to end users

and stakeholders (perhaps the most important dimension!).

80 Chapter 3 – Implementation strategies

3.2 INFORMATION TECHNOLOGY
CONSIDERATIONS
There are several questions which must be answered when determining
how to satisfy the requirements of a new IM system: what is the right
package (hardware and software) for my project? Which software,
hardware, and mobile devices are best suited for the purpose? Is an on-
site platform needed or should it be cloud-based? Should a stand-alone
app or software suite be used? Should open-source or commercial off-the-
shelf (COTS) software be used? Should an on-premises installation be used,
or would it be better to subscribe to a cloud-based Software as a Service
(SaaS) solution?

WHAT IS OPEN-SOURCE SOFTWARE?

Open-source software is software that freely shares the underlying source

code so that anyone can inspect, modify, and enhance it.

(Adapted from [Link])

BUY VS BUILD

Should we buy the system and adapt it to our needs, or should we develop
it? Buying may seem preferable in many cases, however there is no
guarantee that COTS or open-source solutions will satisfy your functional
requirements. The cost of buying and then configuring such systems
can be significant, especially when there are unique or highly specialised
requirements. Maintenance and administration can also be challenging,
especially with poorly supported non-commercial packages. The alternative
to buying an existing solution also needs to be carefully considered, since
the risk and cost of building custom solutions can be even more formidable
for most humanitarian organisations.

Chapter 3 – Implementation strategies 81

 COST

Software procurement is not the only factor that determines the total cost
of ownership of a system. It is necessary to also consider the procurement
of hardware (stand-alone computers and servers, storage, security
systems and infrastructure), labour (staff costs are a major consideration
and escalate rapidly when on-premises infrastructure is run well), training
and maintenance (planning for disaster recovery, securely, keeping up to
date with patches, monitoring, etc.). Staff costs are typically the greatest
expense until the scale of enterprise systems overshadow human resources.
In humanitarian contexts, where IT staff capacity is typically limited, it is
important to consider whether on-premises (local) systems can be managed
effectively; if not, the organisation could become exposed to security
vulnerabilities, data loss, and system unavailability. A full explanation
of calculating total cost of ownership is beyond the scope of this guide
but many resources exist on this topic. A good introduction is at https://
[Link]/article/3005705/calculating-the-total-cost-of-ownership-for-
[Link].

CLOUD-BASED VS ON-PREMISES SYSTEMS

Before exploring the merits of employing cloud-based versus on-premises

(locally-hosted) systems, it is important to clarify that there are different
models of cloud computing. For example, some cloud providers give access
to their already deployed software and applications, for example ArcGIS
Online. In this case, we refer to the cloud service as Software as a Service.
Others provide software and hardware that serve as a foundation to build
upon and we refer to this type of cloud as Platform as a Service. Another
type of cloud service is Infrastructure as a Service, which provides flexible
access to remotely-hosted computing infrastructure with servers, operating
systems and storage to build upon. Lastly, there are other cloud computing
models that pair with locally installed systems. Each option has its own
advantages, characteristics and limitations. Some of the largest commercial
providers include Amazon Web Services, Google Cloud Platform, and
Microsoft Azure; each offer a mix of Software, Platform and Infrastructure
as a Service.

82 Chapter 3 – Implementation strategies

Let us consider some noticeable features between on-premises and cloud
systems.

Connectivity
Cloud-based systems provide on-demand access with real-time
communication for teams and project management in different locations
regardless of the distance. This requires having reliable and high-speed
internet access. An on-premises system will probably not provide that level
of accessibility to those without direct access to the in-house network.
Allowing external access to an in-house network requires a stable internet
connection and establishing a secure access method such as a virtual
private network. A cloud-based system provides on-demand access as well
as real-time communication for teams, but loss of physical control over
equipment. It also offers the possibility of administration from different
locations. Internet connectivity and bandwidth are critical considerations
when using a cloud-based provider, since users working in environments
that have unstable internet access, limited bandwidth or a total lack of
access in the field, will need to be able to work while disconnected from
cloud-based services.

Scalability
Upgrading a cloud server is just a matter of a few clicks and maybe a
restart of the server. Upgrading disk space, memory, CPU capacity and
bandwidth is relatively easy, fast, and requires no actual installation of
hardware. The major cloud service providers offer control panels that allow
system administrators to manage and monitor their instances (servers).
Alternatively, when using on-premises servers, upgrading the disk space,
memory or processors requires buying the right hardware, installing it and
mounting it in the intended machine. It requires knowledge of the hardware
and operating system in order to successfully achieve the required result.
There is also the risk of compatibility and availability issues with regards the
hardware, especially in hard-to-reach areas.

Chapter 3 – Implementation strategies 83

 Security
If there is a need to control and limit access to certain users of the system, a
stand-alone option is very secure, by installing the system in your premises
and allowing individual access through secure machines, especially if it is
not connected to the internet. Alternatively, many cloud-based systems
provide robust security, maintained by extensive teams of staff with
specialised skills. Large cloud providers invest heavily in their system and
security. It is important to recognise the fact that an on-site system requires
ongoing access for skilled staff to ensure it is properly patched, upgraded
and maintained, to stay up to date with security threats and vulnerabilities.

In the following table are some cost drivers for on-premises and cloud
systems.

ON-PREMISES CLOUD-BASED

Capital expenditure typically required Low initial expenditure (operational

to obtain the assets (hardware and expenditure vs CapEx).
software).

Variable monthly cost.

Fixed monthly cost.

Off-site backup cost is comparatively low.

Off-site backups have a cost implication.

Relatively low operational costs

Increased maintenance and operational as provider supplies IT staff, the
costs related to power consumption, pay-per-use model, lower / shared power
system backups (if on-site), IT staff, etc. consumption.

Cost of maintaining skilled IT staff to Competent IT staff supplied at

ensure a secure system is a considerable comparatively low cost due to economies
expense. of scale and included in monthly fee.

84 Chapter 3 – Implementation strategies

The shift towards cloud computing picked up rapidly from around 2010. By
2020, the majority (60%) of servers sold were to cloud providers rather than
to individual organisations for use in their own data centres. (Carey, 2021)

To summarise cloud versus on-premises considerations:

• Cloud tends to be advantageous for cost, uptime, scalability

and ease of use;

• On-premises tends to be advantageous for localised control.

OTHER CONSIDERATIONS

Beyond the choice between buy vs build system, open source vs

commercial, on-premises vs cloud and cost considerations, other points are
also important to keep in mind when choosing the right system for your
needs.

Accessibility
There is the question of accessibility regarding otherwise enabled people
(reading, typing challenges), as well as cultural barriers and preconceptions
regarding system usage and the diversity of system user groups (such as
gender, age, literacy and education level, language, and symbology use).

Support
With any system, support will be needed at some point. It will usually be a
mix of in-house staff and technology provider support, depending on the
complexity of the issue. Proprietary systems will usually have a defined
support mechanism in place, but open-source systems may or may not have
an active community that can help. In either case, it is necessary to have in-
house capacities to at least help with the implementation of solutions.

Chapter 3 – Implementation strategies 85

 Localisation and geographic reach
When choosing the right technology, it is necessary to think about the
localisation of the implementation. Indeed, some programmes may not be
available in some parts of the world or may not be used (and thus harder to
implement). Furthermore, technologies have different capacities in adapting
to different regional and national contexts. These may include being able
to integrate different character sets, time zones, currencies, data formats,
language translations and even different printing paper sizes.

Transferability and interoperability

Most of the time, the data that you input into a system will be needed
in other systems. You want to be able to easily transfer data between
platforms, systems and even between different institutions. The feasibility
and cost of transferability is crucial to consider when choosing a system.

86 Chapter 3 – Implementation strategies

3.3 SYSTEM RISK
MANAGEMENT
Managing system risk begins with identifying all the possible risks involved
in the development, deployment, use and failure of the system, and then
developing suitable responses to these risks. The responses may be pre-
emptive so that we remove or reduce a risk, or may consist of one or more
steps to take when something goes wrong. To manage the risk effectively,
we need to identify the risks with our stakeholder group, determine the
impact that each risk will have for the different stakeholders and then
identify the steps needed to mitigate the risk. An adverse event such as
the loss of access to the system may have different levels of impact on
different stakeholders, so we need to tailor our responses accordingly.
Potential positive events such as increases in project staff or funding need
to be considered as well, to ensure that we identify all possible sources of
uncertainty related to the project and can plan for them.

The risk assessment needs to include all the system components, including
the system environment, with detailed attention given to protecting the
data we are using in humanitarian responses, as misuse of the data could
endanger the population. The extent of a risk assessment needs to match
the size of the project and can range from a simple matrix as shown below,
to a dedicated team project with multiple documents.

Chapter 3 – Implementation strategies 87

 LOW MEDIUM HIGH EXTREME

• Acceptable • As low as reasonably • Generally unacceptable • Intolerable

• Ok to proceed practicable • Seek support • Place event on hold
• Take mitigation measures

SEVERITY

ACCEPTABLE TOLERABLE UNDESIRABLE INTOLERABLE

Little to no effect on Effects are felt, but not Serious impact to the Could result in disaster
event critical to outcome course of action and
LIKELIHOOD outcome

IMPROBABLE
Risk is unlikely to occur

POSSIBLE Inability by NMAA to Unauthorised system Data loss

maintain the OS access System failure
Risk will likely occur
Improper system
maintenance

PROBABLE DB schema change Continued system

after data ingestion changes
Risk will occur

Figure 3.1 – Risk assessment matrix

The International Standards Organization provides widely-employed risk

assessment techniques and offers the following risk assessment process:

1. Plan the assessment – define the purpose and scope of the

assessment, understand the context of the assessment,
engage with stakeholders, define the assessment objectives,
consider the human, organisational and social factors that
impact the project, and lastly, review the criteria for the
decisions taken.

2. Collect and analyse data and develop a model reflecting the

project environment.

3. Apply risk assessment techniques – identify risk,

determine sources, causes and drivers of risk, investigate
the effectiveness of existing controls, understand the
consequences and likelihood of the risks, analyse interactions
and dependencies, and lastly, understand the measures of
risk.

88 Chapter 3 – Implementation strategies

 4. Review the analysis – verify and validate results, conduct
uncertainty and sensitivity analyses, carry out monitoring and
a review of the risk and assessment.

5. Apply results to support decisions – these are decisions about

the significance of the risk, and decisions that involve making
a selection between options.

6. Record and report the risk assessment process and

outcomes.

Refer to (ISO/IEC 31010:2019) for a collection of techniques to apply in

the risk assessment, ranging from brainstorming to surveys, checklists,
scenario analysis and many more. There are numerous techniques available
for conducting a risk assessment, but again it is critical to ensure that the
assessment scope and detail match with the size of the project to ensure
the effective use of resources and management of risk; a small project,
therefore, does not warrant a 3-month risk assessment and neither does a
multi-year project deserve a two-day risk assessment.

The risk management plan must clearly communicate the risk, associated
impact and the responses that will be activated, along with the response
time, so that stakeholders have a clear understanding and realistic
expectations of the mitigation measures. It is important to balance the
costs of the mitigation measures with the financial and / or operational
impact of the risk. For example, it could be decided that up to 15 minutes
of access issues per day, due to internet connectivity loss in the field, does
not warrant the deployment of alternative internet connections at all field
office locations, as this additional cost will not be outweighed by the loss of
productivity.

Chapter 3 – Implementation strategies 89

 3.4 FUNCTIONAL DEPLOYMENT
A new system’s functionality, originally defined as individual use cases and
then deployed in the form of requirements, should be iterative, graduated
and targeted to specific user groups. That is, a smaller test group of
volunteers should be identified and engaged through the deployment cycle,
to debug and improve functionality before it is gradually rolled out across an
organisation.

Deployment of each subsystem will involve significant overlap with legacy

systems, which may need to be employed in parallel until user confidence
allows for full cutover. Create multiple communication channels for users
to provide feedback during deployment – some will prefer ad hoc emails,
others pop-up survey forms, and others in-person meetings / workshops.

Be disciplined whenever there may be a need to deviate from the system

requirements definition, since changes after their acceptance can have
significant risk to the overall success of the new platform. And be sure
to implement and follow a change control process to ensure that any
deviations from the approved requirements are reviewed carefully before
being adopted. Quality assurance processes (ISO/IEC/IEEE 15288:2015)
will guide implementation, a key part of the life cycle of a new system, and
should involve checklists, audits and root cause analysis (as required) until
the system is fully operational.

Track usage patterns to see if the system is used to its full capacity, but
ensure that your organisation acts on the insights gained from the analytics
to ensure that the system adds value to the organisation. (Marchand &
Peppard, 2013) Use a development environment in custom development,
where the development environment fully replicates the production
environment, to reduce issues arising from differences between the two
environments.

90 Chapter 3 – Implementation strategies

3.5 ORGANISATIONAL
CHANGE MANAGEMENT
The decision to introduce a new system should be driven by organisational
stakeholders who will benefit from it. The decision should not be made
solely by technologists or systems engineers who would then need to ‘sell’
it to users.

Because systems engineering engages stakeholders very early in the design

process, they should feel a sense of ownership when the system is finally
implemented. Nevertheless, there is always going to be some resistance to
change, especially when major leaps in the use of technology are involved.
Therefore, sustained engagement with department managers and senior
leadership across an organisation is essential to (a) ensure consistent
messaging about the implementation and operational use of a new system;
(b) address stakeholder concerns; (c) deliver user-specific and general
training; (d) encourage, collect and apply user feedback; and (e) minimise
disruption at each stage of implementation.

Systems engineers should actively engage human resources (HR)

management throughout their projects. For example, a new system may
require an initial orientation and regular training / re-training of employees.
Unless these employees are contractually obliged to complete the training,
a new system becomes vulnerable to (a) the opting out of intended users,
and (b) misuse due to skills deficiencies of users.

HR departments are the entry point of new personnel to an organisation; if

the standard protocol for new employee orientation includes a mandatory
type of systems training, it will ensure that a new system does not
become vulnerable to staff turnover / attrition over time. Engaging with
organisational stakeholders at the onset of the process ensures the buy-
in of the different stakeholders and helps them take ownership of the
development and implementation process, which reduces the resistance
to change that is inevitably encountered with all organisational changes.
It is imperative to outline the common goals of the new system and

Chapter 3 – Implementation strategies 91

 distinguish the benefits that will be realised by each stakeholder or group
of stakeholders (user types) so that they have a clear understanding of the
reason for the change. This eases the change from the current state to the
desired end state.

3.6 VERIFICATION AND

VALIDATION TESTING
As explained earlier in this guide, verification is the process of confirming
that a system (or a system element) fulfils its specified measures of
performance (MOPs), whereas validation is the process of confirming
that it fulfils stakeholder needs in an operational context according to
specified measures of effectiveness (MOEs). Verification can be performed
by objectively testing MOP criteria included in the system requirements
definition, whereas validation may be more subjective, and therefore require
an independent assessment of user satisfaction as defined by the MOEs. A
peer group selected from operational users at various levels of seniority can
be an excellent strategy to validate a system once it has been deployed.

The process for acceptance testing will be dictated by the system

requirements documentation, and any modifications that may have
occurred since the completion of the design phase.

92 Chapter 3 – Implementation strategies

3.7 FINAL DOCUMENTATION
One of the greatest strengths of systems engineering-based design is its
disciplined approach to documentation. Whilst it doesn’t necessarily need
to be excessive or too onerous, documentation should ensure a sufficient
record of the design and implementation decisions, acceptance criteria, as
well as initial operations guidance. The system design and implementation
documentation should include some or all of the following components:

• Concept of operations, providing a high-level description of

the system;

• Functional requirements definition, containing the

functional and non-functional requirements as well as use
cases / user stories identifying the implementation of the
required business logic;

• System requirements definition, that may include a:

◦ Detailed deployment plan for each subsystem of

the overall solution being deployed or integrated;

◦ Data migration plan with the data structure for

the legacy and new systems, as well as the data
field mappings and migration test cases;

◦ Work breakdown structure work plan with task

scheduling and resource assignments;

◦ Budget with contingencies for life-cycle costing;

• Verification acceptance criteria (quantitative measures of

performance) based on operational technical requirements;

• Validation acceptance criteria (qualitative measures of

effectiveness) based on stakeholder requirements;

• Security and risk management plan, with specific

and general strategies to achieve the performance criteria
established by the system requirements;

Chapter 3 – Implementation strategies 93

 • Recommendations for future enhancement, to capture
any desirable research, development and functionality
that was identified during the design process but that was
excluded in the current system requirements;

• System user guide for front-end users and administrators;

• Data management and system management guides for

administrators;

• Continuity of operations plan for incident responders and

administrators.

3.8 CONCLUSIONS
This guide has hopefully provided the reader with a broad understanding
of how to apply systems engineering within the context of humanitarian
information management. The design and implementation of systems
in complex environments is challenging even for the most seasoned IM
specialists: an SE-based approach ensures sufficient stakeholder ownership
of those systems, as well as robust stakeholder satisfaction in those
systems.

Chapter 4 provides a number of case studies which show how the tools and
methods outlined in this guide have been used around the world.

94 Chapter 3 – Implementation strategies

REFERENCES
Carey, Scott, "Cloud spending outstrips on-premises investments for the
first time," InfoWorld, March 23, 2021, [Link]
article/3612769/cloud-spending-outstrips-on-premises-investments-
[Link]

Marchand, D.A. and Peppard, J., (2013). Why IT Fumbles Analytics.

Harvard Business Review. Retrieved from [Link]
it-fumbles-analytics

Mocnik, Franz-Benjamin, Hongchao Fan, and Alexander Zipf. 2017. “Data

Quality and Fitness for Purpose.” AGILE 2017. Heidelberg: Heidelberg
University. Retrieved August 22, 2021. [Link]
net/publications/2017c%20-%20Franz-Benjamin%20Mocnik,%20
Alexander%20Zipf,%20Hongchao%20Fan%20-%20Data%20
Quality%20and%20Fitness%20for%[Link]

Chapter 3 – Implementation strategies 95

 CHAPTER 4 –
CASE STUDIES

96 Chapter 4 – Case studies

4.1 SISTEMA DE ALERTA
TEMPRANA DEL VALLE DE
ABURRÁ, COLOMBIA
PROJECT CONTEXT

The decades-long armed conflict

between the Revolutionary Armed
Forces of Colombia and the
Colombian government forcibly
displaced millions of citizens
throughout the country. Some seven
million Colombians (approximately
15% of the total population) became
internally-displaced persons (IDPs);
many sought safety in peri-urban
slums, like those which climb up
from the steep valley that cradles the
city of Medellín. Not only did IDPs
flee from rebel-held areas in remote
jungles, but also from drug-related
violence, which by the early 1990s
had made Medellín one of the most Figure 4.1 – View of Santo Domingo,
Medellín (© Firoz Verjee)
dangerous cities in the world.

The valiant effort to break the grip of local drug lords – as well as to
negotiate a peace accord with the rebels – began to show promise in the
early 2000s. The proud, industrious people of Medellín were keen to start
a new chapter in their history, and quickly began to promote the disaster
resilience, environmental quality and economic development of the region.
Local authorities recognised that improved environmental awareness and
natural hazard forecasting was going to be key to addressing the socio-
economic vulnerability of local populations and, therefore, to sustaining the
long-term conditions for peace.

Chapter 4 – Case studies 97

 Figure 4.2 – Aftermath of flash flooding in Medellín (© Firoz Verjee)

In 2007, at the request of the regional government (AMVA, or Área

Metropolitana del Valle de Aburrá), the US National Weather Service
(a part of the US National Oceanic and Atmospheric Administration, or
NOAA) began to design an integrated early warning system to improve
the health and safety of at-risk populations, and to promote the economic
development of the region. The design goals of the Aburrá Valley Natural
Hazard Early Warning System (AVNHEWS, and now known as Sistema de
Alerta Temprana del Valle de Aburrá, or SIATA) were to:

1. Promote peacebuilding and disaster-resilient development;

2. Reduce the loss of life and suffering caused by floods, flash

floods, debris flows, etc.;

3. Enhance water reservoir management practices related to

hydro-energy production;

4. Improve local weather forecasting;

5. Monitor air quality, and promote respiratory health; and,

6. Inform local research, development and education.

98 Chapter 4 – Case studies

In close consultation with local project stakeholders, NOAA defined and
then used these goals to design an integrated information management
(IM) solution using a classic systems engineering (SE)-based approach.
The deliverable was a concept of operations and system requirements
document, which would then be used by a consortium of public authorities,
private companies, academic institutions, and civil society organisations, to
procure, configure and operate within three years. The long delivery time
frame was needed to procure and install modern weather radars, computer
infrastructure, environmental sensors, and other technologies, and to
complete required staff training and institution building.

The figure below details the sequence and timelines of the design and
building milestones.

Figure 4.3 – A systems-based approach (source: NOAA)

Chapter 4 – Case studies 99

 The project began with a pre-design process, which then guided the
development of a detailed design of the main system and each subsystem.
The resultant concept of operations (ConOps) and system requirement
definition (SRD) were then employed to build, commission and operate
SIATA.

A decade after it became operational, SIATA is a remarkably successful

example of SE-based design. New subsystems have recently been added to
the original system design, allowing stakeholders to:

1. Monitor seismic events and support earthquake research;

2. Manage wildfire risk; and

3. Develop locally-engineered sensor technologies, with a view

to commercially producing and exporting these technologies
to other regions of South America.

SIATA provides an inspiring example of how the systems-based approach

has been used to design an IM system in a peacebuilding / post-conflict
context. Here is a brief summary of the strategies employed by the project
team to lay the foundations for SIATA’s success:

Pre-design concept planning – when NOAA’s expertise was initially

requested by AMVA, the project requirements were not specific enough
to begin detailed design of the desired system. This is quite normal
with complex systems, and so a four-month process of pre-design was
undertaken without any future commitment of resources. This was sufficient
time to complete a round of introductory meetings with key stakeholders
in Medellín, a review of background reference materials, and to prepare
an inventory of available skills, equipment, data and funding sources. The
pre-design conceptualisation of SIATA also helped to calibrate stakeholder
expectations, and confirm that the project partners understood their roles as
well as the project goals, timelines, and so forth, of a more detailed design
process.

100 Chapter 4 – Case studies

Figure 4.4 – Elements of an effective early warning system (© Firoz Verjee)

Figure 4.5 – SIATA’s hydro-meteorological forecasting sub-system elements

(source: NOAA)

Chapter 4 – Case studies 101

 Project ownership & funding – SIATA’s (a) design, (b) construction, and
(c) operation was 100% funded by AMVA and its project partners, which
guaranteed strong local buy-in, and ensured the focus of the stakeholders
on the project. The US government did not contribute financially to the
project, although it is extremely common for IM projects to be entirely
funded by donors to the developing world (even a shared contribution
between a donor and recipient is preferable, and should be pursued
even in fragile, post-conflict situations). In addition to relying solely on
local money, the project team integrated the capacity of local institutions
whenever possible, and only recommended external skills, methods or
technology when there was no alternative. This not only improved long-
term sustainability, it also increased stakeholder commitment and reduced
technology-transfer risks.

Extensive stakeholder consultation – although NOAA has leading expertise

in hydro-meteorological forecasting and environmental forecasting, its
engineers and scientists did not attempt to design the various subsystems
of SIATA without undertaking many months of strategic and operational
consultations with the project partners. This involved a series of technical
seminars, field visits, data / system analyses, and meetings with each
project partner at their respective facilities in Medellín and Bogotá. The
consultation process later grew to include high-profile press events, political
and diplomatic exchanges, and only then the production of the SIATA SRD
for peer review and final acceptance. Whilst expensive and time consuming,
these consultations were an indispensable source of indigenous knowledge,
scientific data, functional needs and other critical types of design inputs.

102 Chapter 4 – Case studies

 Figure 4.6 – Various examples of stakeholder engagement during SIATA’s
design phase (© Firoz Verjee)

Subsystem design – the figure below illustrates how SIATA was designed
as a system of subsystems, built out of smaller subsystems. Each primary
subsystem was engineered by specialists in the required disciplines, who
then produced a subsystem design plan based on their consultations,
research, and analysis. These plans were structured as follows:

1. Statement of purpose of subsystem;

2. Design criteria;

3. Description of existing capabilities;

4. Description of proposed capabilities;

5. Qualifications & methods;

6. Implementation plan:
a. Implementation activities (by task and sub-task);
b. Schedule (timeline of each task and sub-task);
c. Roles & responsibilities (by task);

Chapter 4 – Case studies 103

 7. Required resources;

8. Human resources training & development plan;

9. Quality assurance;

10. Risks & assumptions;

11. Estimated budget (by task and by type of expense);

12. Conclusion & recommendations;

13. Appendices:
a. Recommended reading;
b. Design planning & analyses reports;
c. List of solution providers / commercial vendors.

Integration of each subsystem design plan into a single, holistic system

design plan very quickly revealed inefficiencies and synergies between the
subsystems, and confirmed the priorities for long-term investment in the
expansion of SIATA. A consolidated description of overall activity, timelines,
costs and stakeholder roles was then presented by NOAA to the project
consortium as part of the final deliverable of the design process.

Given the serious funding implications of the project, English and Spanish
executive-level presentations were also delivered so that senior decision
makers could understand and be confident about supporting the initiative.

104 Chapter 4 – Case studies

Figure 4.7 – SIATA's hydro-meteorological forecasting subsystem elements
(source: NOAA)

Chapter 4 – Case studies 105

 Partnership diversity – although the consortium seemed overly complex
during the initial phase of the project, in retrospect it was the broad
level of interest in SIATA that enabled its success. Whilst not all partners
were expected to contribute equally, the large enterprise formed by
governmental, academic, non-profit and commercial institutions created
extraordinary project resilience, self-perpetuation, and impact.

KEY LEARNINGS:
• Stakeholder engagement must begin on Day 1, and when
effective, can result in extraordinary success even in complex
environments;

• Civil society, academia and public-private sector partnerships

are crucial for long-term sustainability, and inclusive
outcomes;

• Empowerment of a wide range of users / stakeholders is a

key role for the systems engineer from start to finish;

• Modular design, involving an array of subsystems, enables

complicated systems to be successfully deployed as
resources permit, and adapted as requirements evolve;

• Even with best practices in SE design, guidance by an

experienced partner during the design phase is indispensable
to the long-term impact of any IM system.

106 Chapter 4 – Case studies

USEFUL LINKS
The SIATA project is an outstanding example of sustainable technology
transfer and systems engineering. Visit the following links to learn more
about the project:

[Link]
fronteras/articulo/el-sistema-de-alerta-temprana-del-valle-de-aburra-ayuda-
a-evitar-tragedias-medioambientales/545058 (in Spanish)

[Link]
aburra-valley

Channel:

[Link] (in Spanish)

Programme Description:

[Link] (in Spanish)

[Link]
ku9gYjgmSacoDFCuCxYd (in Spanish)

[Link] watch?v=bWJ1xVepVTM&list=PLbNSqpW6px-
Ud9ehBvsoZpSMEIOhnzGr6n (in Spanish)

Interviews:

[Link] (in Spanish)

Chapter 4 – Case studies 107

 4.2 ENTERPRISE GIS FOR
OSCE SPECIAL MONITORING
MISSION TO UKRAINE

BACKGROUND

The OSCE Special Monitoring Mission to Ukraine (SMM) was deployed on

21 March 2014, following a request to the OSCE by Ukraine’s government
and a consensus decision by all 57 OSCE participating States. The SMM is
an unarmed, civilian mission, present on the ground 24/7 in all regions of
Ukraine. Its main tasks are to observe and report in an impartial and
objective way on the situation in Ukraine; and to facilitate dialogue among
all parties to the crisis.5

The SMM produced a range of

public and internal reports based
on field observations generated by
hundreds of monitoring officers
located across the country. Because
its mission grew quickly and without
a robust, modern IM strategy, the
SMM struggled with the efficient
collection, storage, analysis,
dissemination and reporting of data
generated by its unmanned aerial
Figure 4.8 – OSCE SMM patrol vehicles, vehicles, cameras, and monitoring
Ukraine (OSCE SMM 2018)
teams.

5 "OSCE Special Monitoring Mission to Ukraine," OSCE, [Link]

mission-to-ukraine

108 Chapter 4 – Case studies

The benefits of migrating to an enterprise-wide geographic information
system (GIS) were increasingly obvious. Donor support was secured in
2017 and in September 2018, under US government funding, the GICHD
and Esri began a multi-year project to modernise and integrate the SMM’s
IM practices. In addition to transforming data management systems, the
project also aimed to improve the situational awareness, communications,
security, and safety of SMM employees working in the conflict zone.

Figure 4.9 – OSCE SMM observers with Ukrainian-led forces (OSCE SMM 2019)

WHY SYSTEMS-BASED DESIGN?

An SE-based approach was required because of the complex, dynamic

nature of the SMM’s workflows and its reliance on mission-critical
legacy systems. Maintaining operational continuity and managing the
risk associated with transition to a new, fully integrated IM system were
strong arguments for using a systems-based approach for the design and
implementation of the SMM’s Enterprise GIS (or EGIS).

Chapter 4 – Case studies 109

 ROLES & RESPONSIBILITIES

US government (donor): the US State Department’s Bureau of Conflict and

Stabilization Operations was the sponsor of the project; it hoped to not only
reduce the SMM’s IM challenges in Ukraine, but to develop a replicable
model for assisting with other missions elsewhere around the world.

The OSCE Special Monitoring Mission to Ukraine (beneficiary): as the host

organisation and primary user of EGIS, it was critical for the SMM to play
a central role in the design, development, and deployment of the platform
across its units. This ensured ownership and long-term sustainability and
reduced some of the project risks. The SMM’s information management
department was the primary stakeholder within the SMM, and its GIS
coordinator served as its EGIS project manager. The project manager was
supported by a small ad-hoc team from the SMM’s IM, IT and Operations
departments.

The GICHD (grantee): as noted in Section 2, the complementary roles of a

systems engineer and a project manager can be combined when projects
don’t require dedicated specialists to serve in each role. Therefore, the
GICHD’s systems engineer served as the EGIS project lead, providing
overall management of technical and financial matters, as well as work plan
scheduling, monitoring, and donor communications. The project lead was
assisted by a full-time project support officer, with primary responsibility for
contract administration, but also many other responsibilities as required,
including multilingual research and communications.

110 Chapter 4 – Case studies

Esri (contractor): Esri is the world’s leading GIS solutions provider,
and is highly qualified in deploying enterprise systems. Because the
SMM was already a user of Esri's ArcGIS software, the project partners
adopted ArcGIS-based solutions by default when defining the functional
requirements of the desired IM system (Non-Esri solutions were employed
only when a suitable capability was not already available within ArcGIS.)
Esri then translated them into system requirements, addressing ArcGIS
software, other commercial off-the-shelf (COTS) software, hardware and
services. Esri’s team included an EGIS senior project consultant, system
architects, software developers, application specialists, instructors, and
contract managers, as well as sub-contractors like MDA (satellite imagery
solutions provider), Hewlett-Packard (hardware provider) and several COTS
software providers.

Figure 4.10 – Planning to operationalisation: SE phases of EGIS with

completion levels (source: SMM 2020)

Chapter 4 – Case studies 111

 PROJECT WORK PLAN

As indicated in figure 4.10, the EGIS project the EGIS project was originally
structured in four phases. These phases serve as the basis for Esri’s
contractual task orders and represent the EGIS work breakdown structure
(WBS) at its highest level.

The EGIS work plan illustrates the lengthy timelines that can be required
to successfully deploy a custom IM system, even when there is no custom
software development. The following section highlights each of the five
project phases.

PHASE 1 – INITIATION & PLANNING (SEPTEMBER 2018

– MARCH 2019 / MONTHS 1–7)

Despite the understandable pressure to deploy the new IM system as

quickly as possible, all parties agreed that no implementation could begin
until the SRD had been officially approved. This avoided the classic error
of procuring technology prior to (a) securing stakeholder buy-in, and (b)
designing an effective solution around the specific functional requirements
of those stakeholders. It may be tempting, however, to impose a solution
on users of an IM system in order to show immediate results, but building
agency-wide ownership before deployment through SE processes is
essential. In complex environments like that of the EGIS project, nearly
seven months were required for the project kick-off, to complete stakeholder
consultations and finalise the SRD.

This included the time required to negotiate partnership agreements,

secure data / system access privileges, and establish project management
protocols – prerequisites for most IM projects but often underestimated in
the work plan.

112 Chapter 4 – Case studies

Project launch – the EGIS project partners started with preparing for, and
then hosting, a high-profile kick-off event to launch the initiative at the
SMM’s headquarters in Kiev, Ukraine. The objective was to introduce the
team’s leadership, set realistic expectations, generate excitement, establish
a broad level of host-agency support, and identify potential concerns. While
such events can be purely symbolic, they can provide a systems engineer
with a unique preview of the project environment and the needs of various
stakeholders.

Protocols – institutional necessities like partnership memoranda, non-

disclosure agreements, monitoring plans, terms of reference, IT clearances /
access privileges, legal and taxation consultations, etc. involved substantial
effort during and even after Phase 1 of the project. Ultimately, it is the
project lead’s duty to satisfactorily complete these protocols if they have not
been addressed prior to the initiation of the project.

Governance – soon after the project launch, the SMM created a steering
committee to provide oversight and to support to their EGIS project
manager. The steering committee was composed of a senior executive
(SMM’s deputy chief monitor), the managers of the IM, IT, Operations,
HR / Finance and Security & Safety departments, as well as personnel
as required. The committee met monthly to review the project, resolve
problems, and provide guidance to the SMM’s project manager throughout
the duration of the project.

Stakeholder consultations – the project team documented each of the use

cases defined during the stakeholder consultations using the worksheet
illustrated in Chapter 2 and available from the guide’s resource website
([Link] This tool was used to capture the
functional requirements of various stakeholders in simple, user-oriented
phrasing. Some 48 formal consultations were conducted by the team across
the SMM during Phase 1, resulting in 63 unique EGIS use cases. Particular
effort was made to avoid biasing the outcome of these consultations and
to apply a user-centric (not a technology-centric) approach in order to
extract the needs of each user group. Consultations typically involved
a combination of brainstorming sessions, demonstrations, and iterative
development of each use case until it was satisfactorily completed.

Chapter 4 – Case studies 113

 Functional requirements analysis – once it was clear that the consultative
process was sufficiently exhaustive, the project team began to transform
the use cases into a formal set of functional requirements. These were
technical but made no reference to specific technologies, to ensure they
represented the host agency’s priorities without bias to any commercial
solutions provider. Even more importantly, the EGIS functional requirements
were initially drafted by the SMM and not the GICHD or Esri, to ensure they
correctly represented the host agency’s priorities, organisational culture,
and operational structure.

Concept of operations – once the functional needs were defined, it became

possible to develop a ConOps. For EGIS, this was a high-level description
of what was envisioned as a system of systems. The ConOps offered
a simplified operational picture of how EGIS was going to be used to
connect hundreds of end users located in the field, regional offices and
headquarters, by integrating a variety of specialised subsystems through a
common IM platform.

As illustrated in figure 4.11 below, the ConOps schematic shows how a

multiple data source subsystem would feed monitoring information into
several administration subsystems. These hosted the data, services and
technology to support user-oriented visualisation / analysis subsystems.
Collectively, these subsystems needed to create a common operating
picture, to generate various types of reports, and to inform the SMM’s
mission planning subsystems. These subsystems guided the collection of
more data by the SMM’s monitoring teams in the field, creating a cycle
of IM activities supported by a new enterprise geographic information
management system (EGIS).

114 Chapter 4 – Case studies

Figure 4.11 – Concept of operations diagram (SMM 2019)

Chapter 4 – Case studies 115

 System requirements document – the final design was defined through the
preparation of an SRD, by Esri (the selected solutions provider). The SRD
converted the functional requirements and ConOps into a clearly defined
set of specifications for all software and hardware technology (including
enterprise-wide licencing requirements), services, capacity development,
testing, and long-term operational maintenance of EGIS. It contained
detailed system architecture maps, and explained how the operational
performance criteria would be achieved (high availability of critical
functionality, recovery point objective, recovery time objective, etc.).

Formal acceptance of the EGIS SRD by the project team leadership marked
the completion of Phase 1, and their readiness to begin procurement,
configuration and training activities.

PHASE 2 – SYSTEM CONFIGURATION &

IMPLEMENTATION (MARCH 2019 – APRIL 2020 /
MONTHS 7–16)
The SRD should provide a clear road map to a project team, but the project
team was braced for design detours after they transitioned to Phase 2.
This is normal, especially within the context of humanitarian operations,
and a systems-based approach is particularly helpful when conditions are
unpredictable and dynamic:

Essential vs non-essential functionality – each functional need was

determined to be either (a) required, (b) desired, or (c) optional. This was
done in consultation with the SMM’s various users, and it helped the
project team focus on delivering core capability before enhancing EGIS with
interesting but less critical functionality.6

6 Required = essential to mission. Desired = non-essential but unquestionably helpful to mission.

Optional = non-essential but potentially helpful to mission.

116 Chapter 4 – Case studies

Use case tracking – in order to monitor completion progress, the EGIS
project team used various Microsoft tools to track each use case as they
progressed from backlog to completion.

Figure 4.12 – Use case tracking dashboards

Modified agile approach – although the SRD was quite thorough, it did
not attempt to be overly prescriptive. The SMM’s realities changed daily,
and some functionality was redesigned during Phase 2 using an iterative
agile-like approach; that is, a minimum viable product was developed for
an SMM user group to test and to react to, before additional effort was
invested. While it is the most commonly-used approach and can be the
default approach for some IM system deployments, it was primarily used
by the EGIS team in cases in which the end users could not be expected to
adequately articulate their needs during Phase 1.

Chapter 4 – Case studies 117

 Addition of new phase in work plan – the original EGIS work plan had only
four phases, but the growth in the scale of the project, due to unplanned
requirements, and the availability of funding provided justification to add
a new phase, called Phase 2+ – Enhanced system configuration &
implementation (May 2020 – August 2020 / Months 17–23). The creation
of a separate phase for development of the EGIS platform ensured that core
system functionality was satisfactorily completed before enhancements
were attempted. The new phase was clearly defined by a new work
package, and concluded with the signing of operational acceptance
documents by the project leadership.

PHASE 3 – MONITORING & CONTROL (JULY 2020 –

NOVEMBER 2020)

With the completion of system development and training, the project team
was ready to deploy the platform to each user group. Operational roll-out
included (a) system monitoring using back-end specialised software
(ArcGIS Monitor) installed during Phase 2, and (b) satisfaction monitoring,
based on statistical usage reporting, feedback surveys, and user experience
workshops. The team found it important to build in a sufficient period for
monitoring to allow the project team time to address system deficiencies,
deliver additional training / coaching / support, and confirm IM system
acceptance before close-out.

PHASE 4 – SUPPORT & CLOSE-OUT (NOVEMBER 2020

– DECEMBER 2021)

EGIS was built from COTS technology that was well documented, but the
project team still allocated a significant period of time to develop custom
references for the SMM’s various stakeholders. And although system
documentation should be continuously updated throughout a project, the
final phase of EGIS IM involved formal publication of the following user
references by the project team:

• Group-specific user references / standard operating procedures.

• Database administration manual.

118 Chapter 4 – Case studies

 • System architecture & maintenance manual.
• IT continuity of operations plan / incident management plan.
• In-house training curricula, videos & materials.

These types of references promote the long-term sustainability of a new

IM system, and should be concise, factual, understandable and accessible.
Well-documented systems have a much better chance of surviving the
impact that skills attrition and staff turnover will have over time; the
systems engineer should therefore insist on robust references to minimise
dependence on the project team after it completes the delivery of a new
system.

KEY LEARNINGS

This case study has hopefully illustrated how IM systems can be deployed
in the peacebuilding context using a systems-based approach. The project
shows that:

• Conflict-related deployments are unpredictable and require

both discipline and agility;

• Risk management is a key role for the systems engineer from

start to finish; and

• COTS and professionally-hosted solutions are generally

(but not always) preferable, especially when IT capacity is
constrained, and sustainable, scalable solutions are required.

Chapter 4 – Case studies 119

 4.3 INFORMATION
MANAGEMENT SYSTEM
FOR MINE ACTION

TAJIKISTAN INFORMATION MANAGEMENT

SYSTEM FOR MINE ACTION (IMSMA)
CORE IMPLEMENTATION

BACKGROUND

At the end of 2017, the Republic of Tajikistan had just under 7.46 km2 of
mine contamination across 153 confirmed hazardous areas, and almost
1.35 km2 of suspected hazardous area (SHA) across 59 unsurveyed
minefields. The 59 SHAs equate to 45 remaining tasks to be surveyed, as
some tasks contain multiple minefields, potentially laid at different times
during different conflicts and because minefields are counted separately if
they are more than 500 metres apart. The mined areas are located in 13
districts in three provinces of Tajikistan.

The overall baseline contamination at the end of 2017 was a small

reduction compared to the end of the previous year (7.76 km2 of confirmed
contamination and 1.97 km2 of suspected mined area).

Mine contamination remains in the provinces of Khatlon and the Gorno-

Badakhshan Autonomous Region along the Afghan border (reported
to contain 60,357 anti-personnel mines), as well as in the central region.
Shamsiddin Shohin district (formerly known as Shuroobod district) in
Khatlon province is the most heavily mined district. Mines were laid in and
around military positions on hilltops overlooking the Panj river valley, mostly
delivered remotely by helicopter or laid by troops who were moved in and
out by helicopter. Consequently, there are no established roads or tracks to
access the minefields for survey or clearance.

120 Chapter 4 – Case studies

The battle areas in question are mainly recorded as hazardous areas due
to past accidents involving unexploded ordnance or reports from local
communities. Resurvey of most of these areas is required to determine
whether further evidence of explosive remnants of war exists, including
cluster munition remnants.

WHY SYSTEMS-BASED DESIGN?

The Tajikistan National Mine Action Centre (TNMAC) began development

and implementation of a priority setting-based approach to identify
contamination and plan tasking clearance. To make this effective, a robust
IM system which can aid in visualising, modelling, and clearance efforts
was necessary. To develop this, an SE-based approach was required due
to the complex social, environmental, and geographical nature of the
contamination. As Tajikistan nears completion and moves into the long-
term risk management phase, it was necessary to provide tools which
interactively visualise potential residual contamination risk for ongoing
development initiatives.

ROLES & RESPONSIBILITIES

TNMAC is the mine action authority which all operators report to. TNMAC
owns, manages and is responsible for the national database, tasking and
standardisation.

The GICHD: as noted in Chapter 2, the complementary roles of a systems

engineer and a project manager can be combined when projects don’t
require dedicated specialists to serve in each role. Therefore, the GICHD’s
systems engineer served as the IMSMA Core project lead, and provided
overall management of technical as well as financial matters, in addition to
work plan scheduling, monitoring, and donor communications. The project

Chapter 4 – Case studies 121

 lead was assisted by a part-time consultant with primary responsibility
to assist in the development of the IMSMA Core system as required –
including the development of custom tools.

IMSMA Core is a system of tools and processes that can be configured to

fit national programmes’ specific operational and reporting requirements,
which provide access to information for a wide range of stakeholders, foster
information sharing and provide near-real time maps and reports on the
extent of land contamination. It is a knowledge base for the use of GIS in
mine action, designed so that mine action actors can contribute to it and
continuously improve it over time. IMSMA Core is the next generation of
IMSMA, developed and supported by the GICHD.

PROJECT WORK PLAN (FEBRUARY 2018 – DECEMBER

2019)

The Tajikistan IMSMA Core was structured in four main phases over two years:

1. IM stakeholder workshop (review of IMSMA Core, identify

stakeholder and user needs / requirements):
◦ Information requirement discussion;
◦ Define groups and permissions;
▪ Used to define user access and structures.
◦ Review of currently used forms;
◦ Define process maps;
▪ Used to define workflows.
2. Preparing the national database for migration and designing the
IMSMA Core database:
◦ Address database issues / errors and backlog;
◦ Adapt data entry to Survey123 form;
◦ Test Survey123 form;
3. Workflow design:
◦ Develop workflows (maps and apps created);
◦ Test workflows;
4. Go live.

122 Chapter 4 – Case studies

PHASE 1 – IM STAKEHOLDER WORKSHOP

In order to carry out a full and unified consultation with stakeholders and the
national authority, a stakeholder workshop was organised to understand the
current IM systems in place and define the requirements of the new IMSMA
Core system. Group activities and a series of brainstorming sessions were
facilitated, with all results being recorded and used to guide the IMSMA
Core design.

PHASE 2 – PREPARING THE NATIONAL DATABASE

FOR MIGRATION AND DESIGNING THE IMSMA CORE
DATABASE
Preparing the national database for migration:
The first task was to prepare the existing national database for migration
to IMSMA Core. A full review of the data geometry, duplicate entries,
missing or incomplete entries, calculation errors and identification of all
custom defined fields (CDFs) actively being used in IMSMAng vs ones no
longer needed or in use. This review also provided a list of items for review
and correction in the database, giving the initial guide for preparing the
database for a migration to IMSMA Core. In addition, completing all data
backlogs of reported data in the national database was necessary. A GitHub
was created where issues could be detailed, and progress could be tracked.
Using GitHub proved to be an invaluable tool for collaboration between the
GICHD and the TNMAC and as a repository for solutions.

Designing the IMSMA Core database:

Through the process of preparing the national database for migration,
a clear understanding of the database structure, workflows and current
data collection methods were identified. Throughout the data preparation
process there were discussions on how to improve the data schema, data
collected and how to enter data in the national database. These discussions
led to a plan on how best to approach the development of the IMSMA Core
database. Improvements were identified, which could be implemented in
the IMSMA Core system, as well as identification of where the database
could be updated in accordance with International Mine Action Standards
(IMAS) recommendations.

Chapter 4 – Case studies 123

 Adapting the forms for IMSMA Core:
During the data preparation process, a review of the data collection forms
was carried out. This required identifying the number and types of forms
that are in active use and would need to be migrated to IMSMA Core.
Like the database preparation process, the survey forms were reviewed,
identifying areas for improvements and potential updates following IMAS
recommendations. All necessary CDFs were also identified, and non-
essential or redundant CDFs were noted. Following the review, all actively
used forms were adapted to Survey123 which turned paper forms into
electronic survey forms connected directly to the IMSMA Core database.
Improvements and updates were incorporated into the Survey123 forms as
well. Once the first draft of the new survey forms was completed, a full test
of the forms was implemented. Through the process for adapting the forms
to IMSMA Core, the database schema was developed and prepared.

PHASE 3 – WORKFLOW DESIGN7

Using guidance from the results of the IM stakeholder workshop, and

through discussions conducted during the data preparation process
and adaptation of the forms for IMSMA Core, workflows were updated.
Improved process maps were made for the data collection, entry and
validation processes. While seemingly more complex, the updated process
improved the delegation of tasks and efficiency (see Figures 4.13 and 4.14).

A workflow process involving the use of ArcGIS Pro, web applications and
Survey123 was designed in IMSMA Core to facilitate more efficient data
entry and validation, as well as minimising the potential for human error.
Task workflows were designed in ArcGIS Pro for TNMAC IM officers,
providing an easy guide to the tools and tasks for each stage of the data
entry and approval processes. The workflows give guidelines on the order
of steps to take and present tools for use in each of these steps.

7 Subsequent implementations of IMSMA Core have had database design and workflow design
occur in tandem rather than sequentially, as depicted in this example.

124 Chapter 4 – Case studies

Information dashboards were also designed to support the reporting
requirements of the TNMAC to stakeholders. Once all workflows and
dashboards were completed, a full testing was carried out, and the
necessary adjustments made.

Figure 4.13 – IMSMAng process map #1 (GICHD 2019)

Figure 4.14 – IMSMAng process map #2 (GICHD 2019)

Chapter 4 – Case studies 125

 Figure 4.15 – IMSMAng process map #3 (GICHD 2019)

126 Chapter 4 – Case studies

PHASE 4 – GO LIVE

In December of 2019, IMSMA Core was officially launched in Tajikistan.

The national database was migrated to IMSMA Core, with workflows,
applications and information dashboards in active use. Throughout the
process, the TNMAC operated with their legacy database and IMSMA Core
in parallel. As elements of the workflows, forms and data were ready for use
in IMSMA Core, the TNMAC moved the related activities into operation in
IMSMA Core. This parallel operation process provided for a disruption-free
process, where operations could continue without interruption.

LESSONS LEARNED:

• Parallel operation of IMSMAng and IMSMA Core throughout

the development process provides little to no disruption to
operations. This parallel approach also allows for a gradual
testing of elements in the IMSMA Core design with no risk
to the national database or ongoing operations.

• Clear planning and identification of needs for the

IMSMA Core system must be completed in the first phase of
development. Any large design changes midway through the
project can cause long delays which may ultimately increase
the projected timeline by months.

Chapter 4 – Case studies 127

 DRC IMSMA CORE IMPLEMENTATION
IMSMA Core was also implemented as a pilot project in the Democratic
Republic of Congo (DRC) for the United Nations Mine Action Service
(UNMAS). UNMAS DRC carries out explosive ordnance disposal and
explosive ordnance risk education, reporting to the national authority, but
owning and managing their own database. They are currently updating their
IMSMA Core to UNMAS standards.

Prior to IMSMA Core, UNMAS forms were in Excel and Word, with their
database hosted in Excel / Access. National data standards were being
reviewed, which meant that at some point an adaptation of the database
and forms would be needed to reflect new UNMAS standards. While this
did not occur during the initial development of IMSMA Core, the system
was updated to reflect new UNMAS and International Mine Action
Standards after launch.

As in the case of Tajikistan, information gathered through an initial

stakeholder workshop, and from discussions carried out during the data
preparation process, as well as through adaptation of the forms for IMSMA
Core, led to workflows being updated accordingly. In this case, workflows
were created with a trigger system alerting those responsible for various
tasks. The triggers were designed as email alerts connected to the
database. Using a custom script, database triggers indicated the start or
end of a specific task within various workflows such as managing workflow
status and notifications of activities. Each trigger was sent to the individual
responsible.

IMSMA Core went ‘live’ for UNMAS DRC in 2019, and the following
year further database and reporting updates were made to enable easier
maintenance and updates.

128 Chapter 4 – Case studies

LESSONS LEARNED

The lessons learned from the implementation of the DRC programme were
the following:

• Regular communication within the project team is critical

during iterative design.

• Due to changes in the composition of the project team during

the life cycle of the implementation, the importance of clear
documentation for both processes and design, as well
as the recording of issues, was highlighted, to support the
handover of responsibilities.

• As the IMS was rolled out to additional programmes,

minimum data standards were required to allow data
to be consolidated on a global scale. These minimum data
requirements were then extended to meet local information
needs.

• Missions to DRC by the GICHD and UNMAS teams

highlighted the importance of identifying the most productive
means of working and communicating with in-country staff.
In DRC, an in-person approach was significantly more
effective than remote support.

Following a systems engineering approach, the global information

management system based on IMSMA Core is now being implemented
across all UNMAS operations. Adopting the lessons learned from the
pilot project, the programme is being delivered in partnership with United
Nations Office for Project Services (UNOPS) who serve as the project lead.

Chapter 4 – Case studies 129

 4.4 OPEN-SOURCE IMS
FOR MINE ACTION
BACKGROUND

The Iraqi Kurdistan Mine Action Agency (IKMAA) is responsible for the
following tasks:

1. Clearing all areas of the Kurdistan Region of mines and

explosive hazards;
2. Promoting mine risk awareness and educating the people
of the Kurdistan Region through different media outlets and
school programmes;
3. Providing the necessary assistance to mine victims;
4. Cooperating and contributing to the prohibition of the use
of anti-personnel mines and participating in international
conferences and workshops related to mine action;
5. Coordinating and cooperating with organisations and centres
with the same mandate, within and outside of the Kurdistan
Region, which helps the agency achieve its goals.

WHY DID IKMAA REQUEST AN OPEN-SOURCE IM

SYSTEM?

IKMAA increasingly struggled with the limitations of their legacy, stand-

alone system, as its programme grew to include multiple locations for data
entry across Kurdistan. This resulted in inefficient and time-consuming
data synchronisation between these locations. IKMAA required an online,
web-based centralised IM system that would have lightweight internet
connectivity requirements and would contain basic spatial data visualisation
capabilities. IKMAA requested the Information Management and Mine
Action Programme (iMMAP), in 2021, to develop such a system for them,
with the provision that most of IKMAA’s spatial data analyses would
continue to take place offline using GIS desktop software.

130 Chapter 4 – Case studies

ROLES AND RESPONSIBILITIES

IKMAA is the mine action authority in the Kurdistan Region of the north of
Iraq, and all operators report to them. IKMAA has complete control over the
new open-source IM system and issuing tasks for implementing partners.

IKMAA requested GICHD involvement in the system development

processes. The GICHD is providing guidance and support to IKMAA and
iMMAP in the development of the IMS based on IMAS 05.10 Information
Management for Mine Action, and experience gained in the development of
the IMSMA software.

IKMAA tasked iMMAP with the development of the open-source IM system

as part of its project funded by the U.S. Department of State Bureau of
Political-Military Affairs, Office of Weapons Removal and Abatement, to
develop the IM and GIS capacity of the Iraq mine action authorities. The
new IMS is being developed in-house by iMMAP staff based in Erbil, using
only open-source components to ensure minimal financial requirements for
the continued deployment of the IMS.

PROJECT WORK PLAN (MARCH 2021 – DECEMBER

2021)

The open-source IMS was requested by IKMAA from iMMAP with the
involvement of the GICHD to ensure the integration of best practices from
both organisations in the development of the system. The project follows
the waterfall software development methodology, as most of the system
requirements could be defined at the onset of the project, and consists of
the following phases:

Chapter 4 – Case studies 131

 1. Workshop with IKMAA, the GICHD, and iMMAP to clarify the
following:
◦ System requirements (functional and non-functional);
◦ New features required from the open-source IMS;
◦ Offline or online use of the system?
◦ Technology components of the new system;
◦ Stakeholder roles of IKMAA, the GICHD, and iMMAP.

2. Designing and developing the open-source IMS, to include:

◦ Designing the new system according to the system
requirements;
◦ User-friendly data entry form design;
◦ Dashboards for each humanitarian mine action activity
and for the overall system;
◦ Using PHP and PostgreSQL to develop the new
system to have a relational database management
system (RDBMS) that is compatible with IMSMA Core
and thus simplify any future data migration;
◦ Robust data validation and verification;
◦ Chain of action or business logic for all procedures;
◦ Using OpenLayers for the GIS component of the
system;
◦ Deploying the system on IKMAA’s existing server;
◦ In-house training of IKMAA staff on using the new
system.

3. Migration of IKMAA data to the new system and training in

the system:
◦ Mapping all data to fit the new system’s data
structure;
◦ Finding a suitable solution for IMSMA version data;
◦ Checking and entering data into the system with all
IKMAA offices;
◦ Training IKMAA staff with different user levels, i.e.
users, administrators, and decision makers.

132 Chapter 4 – Case studies

PHASE 1 – WORKSHOP WITH IKMAA, THE GICHD
AND IMMAP

This workshop was the start of work with IKMAA, to discuss the open-
source IM system for mine action and included the three stakeholders, to
facilitate and direct the system development process.

This phase focused on collecting the system’s requirements and capturing

the system’s required business logic. The breakdown below lists the main
steps and outputs:

• In-house interviews with the technical and information

management staff;

• In-house knowledge with similar software to be used as a

valuable reference for all challenges and problems;

• Generation of all the required documents to clearly explain

the system’s requirements, such as use case diagrams,
functional and non-functional requirements, etc.

Functional requirements
1. Creating and designing data entry forms and related tables
dynamically, according to the users’ requirements;
2. Supporting granular permissions by allowing users to access
the data sets and functionalities according to the privilege
granted by the system administrator;
3. Supporting a multi-language interface with the ability to add
new languages when required;
4. Tracing historical data and logs for each field report;
5. Providing the following GIS functionality:
◦ Visualising data on the map;
◦ Supporting online and offline maps;
◦ Enabling the addition and removal of record
geometries such as points, polygons and polylines;
◦ Providing a tool to measure area size and distances;
◦ Providing map printing as PDF files.

Chapter 4 – Case studies 133

 6. Importing data from data sources such as MS Excel, Comma
Separated Values (CSV), etc.;
7. Exporting data as MS Excel workbook files;
8. Providing tools for basic data analysis and visualisation;
9. Optional integration with mobile data collection tools such as
KoBoToolbox and Survey123;
10. A content management system to manage user profiles,
form permissions, country structure and auxiliary data;
11. An email notification system to notify users of updates and
to send weekly and monthly reports to stakeholders and
decision makers;
12. Supporting the printing of single reports or batches of
reports.

Non-functional requirements
1. Response time for creating a form not exceeding five
minutes, based on the current data entry forms used by
IKMAA;
2. Accessing forms restricted to a specified group, allocated in
the system’s permissions table, and accessing authorisation
for management down to a specific field level;
3. Providing a tool to translate terms, keywords and technical
vocabulary from English to all other languages that are
configured in the system;
4. A web map tool allowing for the customisation of the
geometry themes and labels;
5. A web map tool allowing for the transformation of geometry
coordinates from longitude and latitude to the military grid
reference system;
6. A web map tool enabling the automated submission of
geometries into the database by importing the report data
in bulk from external resources such as CSV files or using
bearing and distance measurements for polygons and
polylines;
7. Ability for the system’s backup and recovery mechanism
to restore the system back to a specified date within 15
minutes.

134 Chapter 4 – Case studies

System component selection approach
The overarching considerations for the selection of the component
technologies were based on the following criteria:

• Direct cost in terms of initial purchase, ongoing maintenance

(upgrades and support of the software) and indirect cost in
terms of labour required for system maintenance (user base
size, access to support documentation and prevalence of
technically focused fora / knowledge repositories). All the
components selected are either freeware or open source,
except for the Windows operating system.

• Performance, scalability, and security – Apache, PostgreSQL,

and PHP can run with their default configurations on a
mid-range laptop for web apps to a maximum of 100
simultaneous users. These apps can easily be tweaked to
improve performance, or be migrated to a Linux-based
environment for additional performance gains. Software
bundles such as WAPP (Windows, Apache, PostgreSQL,
and PHP) provide a mix between the Windows open-source
(OS) platform that most end users are familiar with, and the
Apache, PostgreSQL, and PHP components, for an easily
manageable platform that can scale to meet demands.
Additionally, PostgreSQL provides support for spatial data
types, which simplifies the storage of the HMA spatial data.

• Cross-browser and device compatibility – HTML5, which

includes JavaScript and CSS3, is the global web content
rendering standard and by using PHP to generate HTML5
standard code on the server side, the system will be usable
across a wide range of desktop and mobile devices. The
GeoJSON data format similarly provides compatibility with a
wide range of web platforms, thus providing the opportunity
to integrate with other systems in the future.

• Ease of use and troubleshooting – with a WAPP foundation,

the solution would run on the familiar Windows platform
and provide system administrators with easy access to
the component configuration files, source code, and logs
generated by the Apache server and PHP interpreter.

Chapter 4 – Case studies 135

 • Lastly, the primary technical requirement for the system was
that it must allow IKMAA to adapt the database structure and
the web application components independently following
the completion of the system development process. The
use of these mature and widely used technologies ensures
that IKMAA can use a large number of websites and
online communities that provide support for users of these
technologies, and with the plain text file-based configurations
used by these components, whilst editing the components
and the source code will not pose a problem.

PHASE 2 – DESIGNING AND DEVELOPING THE OPEN-

SOURCE IMS

1. Design: the design of the database included the following:

• Designing and modelling the system’s database conceptual

and logical schema. See Figure 4.16, below, for the
conceptual diagram of the database schema;

• Selecting suitable technologies for the software and

hardware components such as the web app development
language, database, etc. The following were defined as the
preferred technology components:

◦ Back-end technologies: PHP (version 7) as the

server-side scripting language, PostgreSQL
(version 10) as the database platform, Apache
(version 4.2) as the webserver, the OS platform
being either Windows or Linux, and GeoJSON as
the main format for spatial data representation;
◦ Front-end technologies: HTML5 which includes
JavaScript and CSS3, Metronic UI package for
themes and layout rendering, OpenLayers (version
6) for spatial visualisation, thus providing support
for the mainstream web browsers, i.e. MS Edge,
Google Chrome, and Firefox.
• Defining the system’s architecture pattern;

• Generating the software’s development documentation, i.e.

the system sequence diagram, entity relation diagram, state
machine diagram, etc.

136 Chapter 4 – Case studies

 Figure 4.16 – Open-source IMS database conceptual schema (iMMAP 2021)

2. Development: all the solutions and models from the design phase were
implemented in the system database and web application development.

3. Testing and verification: testing the completed IM system as a whole

and through the verification process to ensure that the final system meets
the client’s requirements and specifications in terms of business logic and
functionality.

4: Deployment: iMMAP deployed the pilot system to the production

environment at IKMAA’s offices in Erbil to facilitate testing of the new IMS
by different user types in IKMAA. Deployment of the pilot system aids in the
identification of additional functional and non-functional requirements that
did not surface during the initial system design. IKMAA staff received initial
training in the use of the new system, with additional users to be included
in Phase 3.

5. Maintenance: following up users’ requirements after system

deployment and applying code updates as needed for issues discovered
following the deployment.

Chapter 4 – Case studies 137

 PHASE 3 – MIGRATION OF IKMAA DATA TO THE NEW
SYSTEM AND TRAINING IN THE SYSTEM

In this phase, we start with the main data migration process, as during
Phases 1 and 2 we migrated the IMSMA auxiliary data to the new system,
which are labelled as support tables in the new IMS. The migration process
focuses on mapping the extensive data tables and CDFs in the IKMAA
IMSMAng database to a more streamlined database architecture in the new
system. The data migration will include the migration of the IMSMAng Info
versions of data to the new system’s record change tracking mechanism.

A monolithic system architecture was selected for the new IMS, which
means that the user interface and data access / manipulation code are
combined in a single package, as opposed to abstracting the data access
and manipulation code from the user interface code. However, the system
functions are logically grouped and thus see the component units isolated
according to the tasks’ focus, with the application settings and configuration
files separated from the main package to restrict access to the relevant user
permission level.

The following user types are designed to operate in the system in its entirety
with specific roles designed for each user type:

1. System administrator
◦ Create new user and modify existing users;
◦ Grant permissions for system users;
◦ Import data from external data sources;
◦ Export data from the system.
2. System super administrator
◦ This user type has all the system administrator
permissions, in addition to:
◦ Changing system configurations and settings; and
◦ Creating new projects.
3. Form creator
◦ Creating new data entry forms and deploying or
activating the forms for general use;
◦ Modifying or deactivating existing forms.

138 Chapter 4 – Case studies

 4. Form supervisor
◦ Reviewing and approving newly added records;
◦ Reading and writing access to all records
belonging to users under their supervision.
5. Form data entry
◦ Adding new records to the forms that they have
permission to access;
◦ Editing and disabling all existing records that they
have permission to access.

Following on from the completion of the pilot phase with the IKMAA Erbil
offices, the system will be made available to the remaining IKMAA offices
spread across the region and user training will be provided to the new
users. Whilst it is expected that the increase in system users will lead to the
identification of improvements or refinements to the business logic, these
are not expected to have a critical impact on the base system and will be
reviewed with all the stakeholders prior to implementation.

LESSONS LEARNED

In selecting the system components, it was found that while IKMAA staff
have strong technical foundations in RDBMS and the overall management
of IT and IM systems, the use of a Windows-based web application hosting
platform would simplify the management and maintenance of the system
components.

The limited funding available to IKMAA for the implementation of new

IM systems dictated a pragmatic approach to the selection of the system
components, hardware requirements, and the tools required by IKMAA
to manage the system components and the source code. The selected
components can be administered easily using an advanced text editor such
as Notepad++, while the source code can be updated with a freeware
integrated development environment such as Apache NetBeans.

Chapter 4 – Case studies 139

 The internet bandwidth capacity, stability, and coverage is the key risk
indicator that poses a concrete restriction on the amount of multimedia and
text data that can be transferred between a web server and its users across
the region. This limitation underpinned the decision to reduce the use of
images and multimedia to the lowest acceptable level and utilise JavaScript
and Cascading Style Sheets to style the web application components,
generate charts, and provide a pleasing interface for the system users.

The system development used a mixture of the waterfall and iterative

development approaches, by starting with the system foundation
development using a systems engineering approach, and switching to an
iterative approach for the rapid development and user acceptance testing
of the various back-end and front-end components of the web application.
Regular meetings with IKMAA and the GICHD allowed the stakeholders to
provide concrete and relevant input to the design of the web application,
both at the onset of the system design and during the implementation
process. The base system was deployed at IKMAA’s Erbil head offices to
allow for regular interaction and testing of the system, thereby allowing
IKMAA to gain in-depth exposure to the new system and take ownership
at an early stage. This positively impacted on the change management that
is required by IKMAA to embrace the new system. The local implementing
partners will also form part of the user acceptance testing to ensure that
all stakeholders can contribute to the development of a robust system that
works for both the national authority and other stakeholders.

The intermittent internet connectivity necessitates the adoption of a multi-

location deployment of the new system, with a stand-alone node to be
installed at a regional mine action centre. Based on IKMAA and iMMAP’s
extensive experience with the synchronisation of IMSMAng databases, the
choice was made to normalise the database to the third normal form to
simplify the data synchronisation between the two deployments.

140 Chapter 4 – Case studies

Geneva International Centre for Humanitarian Demining (GICHD)
Maison de la paix, Tower 3, Chemin Eugène-Rigot 2C
PO Box 1300, CH – 1211 Geneva 1, Switzerland
info@[Link]
[Link]