Content uploaded by Jonna Järveläinen
Author content
All content in this area was uploaded by Jonna Järveläinen on Nov 28, 2022
Content may be subject to copyright.
Designing a Thrifty Approach for SME
Business Continuity: Practices for
Transparency of the Design Process
Research article – published by Journal of the Association for Information Systems
(https://aisel.aisnet.org/jais/vol23/iss6/ 3), copyright Association for Information
Systems owns the copyright and that use fo r profit is not allowed
Authors
Jonna Järveläinen, University of Turku, Finland, jonna.jarvelainen@utu.fi
Marko Niemimaa, University of Agder, Norway, marko.niemimaa@uia.no
Markus P. Zimmer, Leuphana University Lüneburg, Germany, markus.zimmer@leuphana.de
Abstract
Business continuity (BC) management is an organizational approach to prepare information
systems (ISs) for incidents, but such approaches are found to be uncommon among small and
medium-sized enterprises (SMEs). Past research indicates a gap in approaches that are
designed for SME’s since BC management approaches tend originate from larger
organizations and SMEs lack the resources to implement them. To fill this gap, and to respond
to a practical need by an IT consultancy company, we employed design science research
(DSR) to develop a BC approach for SMEs coined as ‘Thrifty BC Management Approach.’
Jointly with the company’s practitioners, we developed a set of meta-requirements for BC
approaches for SMEs anchored in prior BC literature, the practitioners’ practical expertise, and
the theories of collective mindfulness and socio-technical systems. We evaluated our Thrifty
BC Management Approach with multiple SMEs. These evaluations suggest that the designed
approach mostly meets the defined meta-requirements. Moreover, the evaluations offered
ample opportunities for learning. The design process, unfolding in a real-world setting, was
precarious, rife with contingencies and ad hoc decisions. To render transparent the design
process, we adapt four writing conventions from the confessional research genre familiar to
ethnographic research but novel to DSR. We offer a threefold contribution. First, we contribute
to SMEs’ BC with meta-requirements and their instantiation in a new BC approach (artifact);
second, we contribute with four practices of confessional writing for transparency of DSR
research; and third, we contribute with reflections on our theoretical learning from throughout
the design process.
Keywords: business continuity; small and medium-sized enterprises, design science
research, research transparency, Thrifty BC management Approach
Introduction
Organizations’ dependency on information systems (IS) has meant that different kinds of
incidents from Fukushima (Sakurai & Kokuryo, 2014; Tapanainen & Kamioka, 2013) and the
WannaCry ransom attack (Hern, 2017) to common component breakages and network
outages can cause operational business disruptions with significant impact, especially when
affecting business-critical systems or processes. To prepare, organizations seek to develop
their business continuity (BC) as the capability “to continue delivery of products or services at
acceptable predefined levels following disruptive incidents” (ISO, 2012). While developing BC
is challenging for all kinds of organizations due to the inherent unreliability of technologies
(Butler & Gray, 2006), SMEs face challenges that emanate from their more limited pool of
resources (Botha & Von Solms, 2004; Heidt & Gerlach, 2018; Sullivan-Taylor & Branicki,
2011). Thus, it is not surprising that BC preparations are uncommon among SMEs (e.g.,
Herbane, 2013; Kato & Charoenrat, 2018).
While “IS research provides little guidance for managers […] to enhance business continuity”
(Butler & Gray, 2006), practitioners tend to favor best practice-based BC management
approaches, such as ISO/IEC 27001 or ISO 22301 developed by the International
Organization for Standardization (Hiles, 2011). These standard-based frameworks originate
from larger companies (Backhouse et al., 2006), are geared toward them (Kinnunen &
Siponen, 2018), and assume more bureaucratic forms of organizing than typically found
among SMEs (Bilili & Raymond, 1993). Further, such approaches are too generic for all
organizations (Siponen & Willison, 2009), require extensive documentation (e.g., BC policies,
plans, and strategies) (Freestone & Lee, 2008; Gibb & Buchanan, 2006; ISO, 2012), and
assume niche expertise for implementation (Niemimaa & Niemimaa, 2019). Thus, the
suitability of current BC approaches for SMEs is debatable.
Despite SMEs’ importance for markets, scholars have engaged little in providing BC guidance
tailored for SMEs (Botha & Von Solms, 2004; Herbane, 2019), with rigorous BC approaches
designed specifically for SMEs lacking (Herbane, 2019; Macpherson et al., 2015). The
distinctiveness of SMEs stems from their limited formality and temporal, financial, and
knowledge resources in operations compared to large organizations (Heidt & Gerlach, 2018;
Herbane, 2019). These SME-specific requirements present an interesting opportunity to
explore BC management in an SME context, raising the following research question:
RQ: How can a BC approach for SMEs that considers their specific requirements,
emanating from their limited available resources, be designed?
We approach this question through a practitioner-initiated design science research (DSR)
project aimed at creating a BC approach for SMEs. The design of the artifact is anchored to
theories on socio-technical systems and collective mindfulness to strengthen the practically
oriented BC literature (Niemimaa, 2015b). These theories facilitated the creation of meta-
requirements for a BC approach, resulting in what we coined Thrifty BC Management
Approach. The project responds to the scarcity of IS studies on this topic (Niemimaa, 2015a,
2017), and to calls for more guidance in BC for IS managers (Butler & Gray, 2006) and
especially SMEs (Herbane, 2010a).
Following Kuechler and Vaishnavi’s (2008) DSR model, the paper is structured as follows.
First, we introduce the literature on BC management and provide background on the relevant
aspects of BC for SMEs. Second, we describe our DSR approach. We then formulate the
design problem and develop ten meta-requirements for BC management approaches
applicable in SMEs. Next, we present the Thrifty BC Management Approach for BC as the
design artifact together with the description of the design process. Finally, we outline the
approach’s evaluation. We close with a discussion and conclusion presenting our
contributions.
Knowledge Base—Business Continuity Management for SMEs
The Technical, the Social, and the Socio-Technical Business Continuity
Several approaches exist for BC management and planning (Niemimaa, 2015a) that provide
guidance for organizations on incident preparations and quick recovery (Arduini & Morabito,
2010; Baham et al., 2017). Many of the approaches propose an organization-wide and holistic
approach to BC (Geelen-Baass & Johnstone, 2008; Harris & Grimaila, 2008; Sambo &
Bankole, 2016) that demand a considerable amount of work, produce heavy documentation,
and are designed for larger organizations (Herbane, 2019; Kepenach, 2007; Smith, 2003).
To prepare ISs for incidents, organizations need not only to change the ISs but to broadly
change the social and technical fabric of organizing (Niemimaa, 2017). Typical technical
measures for BC management are backup systems or high-availability solutions, whereas
social measures comprise those such as documentation (e.g., recovery procedures,
responsibilities, plans, etc.), organizational structures and responsibilities, as well as training
and exercising (e.g., Gibb & Buchanan, 2006; Tracey et al., 2017).
Social measures are challenging to implement due to difficulties in translating policy
imperatives into actual practices (Niemimaa & Niemimaa, 2017), but also because employees
tend to not comply with the policies (Moody et al., 2018). Scholars have underlined the
significance of embeddedness as an organizational quality is when “strategic thinking and
participation in the business continuity process […] manifests itself throughout the
organization” as well as “constitutes the organizational processes of leadership, commitment
to which may be seen operating at individual and group levels.” (Herbane et al., 2004, p. 442).
Thus, embeddedness in this context relates to organizational reliability culture (Sawalha et al.,
2015) and to BC awareness rather than to social ties (Adler & Kwon, 2002). Research has
indicated that each BC planning phase contributes to achieving embeddedness (Niemimaa &
Järveläinen, 2013), rather than being an outcome of the whole process (e.g., BS25999).
Considering further the social measures of BC, research indicates collective mindfulness
processes are significant to BC. Butler and Gray (2006) argue that organizational cultures in
which employees can practice resilience and reliability embody processes of mindfulness.
These processes focus on operations, a commitment to resilience, and openly considering the
past (Weick et al., 1999). BC plans become secondary to such issues of context and culture
that enable practicing resilience and reliability. Butler and Gray (2006) further argue for a dual
role of collective mindfulness on technical measures in BC, which can be “enhanced by
(moderation) collective mindfulness” (p. 219) or can increase the influence of them.
The socio-technical perspective is broadly considered a suitable theoretical basis for BC
research (Herbane, 2010b; Niemimaa, 2015, 2017). It makes little sense to carefully plan,
organize, and practice effective procedures of data recovery without technical measures
enabling and supporting this. Similarly, procedures must leverage their action potentials in
case of data loss. A socio-technical perspective on BC stresses the importance of both
technical and the social measures (Herbane et al., 2004).
Business Continuity management in SMEs
Prior literature indicates that SMEs form a specific context and challenge for BC, possibly
explaining their unpreparedness for contingencies (Herbane, 2019; Sarkar et al., 2017). For
instance, Macpherson, Herbane, and Jones (2015) found that small businesses used their
networks, experiences, and combined coping mechanisms to survive crises, contrasting with
more formal and bureaucratic mechanisms found in larger businesses. Further, Cumbie
(2007) studied SMEs’ use of disaster recovery approaches and found several felicitous
managerial and operational practices, for example, managerial planning and geographical
diversity.
A commonly shared view is that the approaches in general disregard considerations of
company size (Bell & Gomez, 2011; Cumbie, 2007; Pinta, 2011). Approaches tailored to SMEs
exist but their suitability is often not specified (e.g., Sambo & Bankole, 2016; Ueno et al.,
2018). Botha and von Solms (2004) identify eight factors that distinguish SMEs from larger
organizations and that have an impact on their BC planning, such as financial performance,
management structure, infrastructure complexity, and SME conduct. While their approach
suggests a localized management of BC risks (e.g., with back-ups and disaster recovery), it
also expects all SMEs to perform the same BC activities as larger organizations (e.g.,
conducting planning and business impact analysis activities).
Resource-availability, a key differentiator between SMEs and larger organizations, is a
significant barrier to SMEs’ resilience (Sullivan-Taylor & Branicki, 2011) and influences SMEs’
BC in several ways: limitations in financial resources, time, and knowhow impact their security
decisions (Heidt & Gerlach, 2018); managers in SMEs must assume several roles (Branicki et
al., 2018); SMEs perceive a lack of necessary skills, knowledge, and information (Chen et al.,
2007); and SMEs have limited resources to confront day-by-day threats (Branicki et al., 2018;
Herbane, 2019), giving them a temporal focus on leadership (Heidt & Gerlach, 2018). Last,
they lack formalism in planning for BC (Herbane, 2019; Kato & Charoenrat, 2018; Vargo &
Seville, 2011), which may in fact contribute to their resilience rather than weaken it (Branicki
et al., 2018; Macpherson et al., 2015). Thus, the SMEs preparations for incidents differs (Bell
& Gomez, 2011), which calls for a SME-specific approach that can aid them in resource-
considerate BC management (Bilili & Raymond, 1993).
To summarize, the prior literature lacks an approach for BC management for SMEs, although
the need for one has been widely recognized. This research aims to fill this gap by designing
a BC approach for SMEs.
Research Approach
We followed a DSR approach to design a BC management approach as an artifact. In what
follows, we outline the methodological details of the DSR project.
Design Process
Following Kuechler and Vaishnavi (2008), we can analytically structure our design process in
four design and reporting cycles (see Figure 1). The linearity of this and the following
description are simplifications of the actual process in practice (Kuechler & Vaishnavi, 2008).
The design project’s first three cycles took place between September 2016 and January 2017.
The evaluation cycle comprises four episodes, two completed in 2017 and two in 2020, which
informed the artifact iteratively.
Figure 1: Cycles and Outputs of the Design Process (adapted from Kuechler and Vaishnavi 2008)
The Problem Formulation to Meta-requirements cycle created problem awareness (Kuechler
& Vaishnavi, 2008). This cycle started with a contact from an IT consultancy company offering
IT services to SMEs who knew the first author to be a BC expert through earlier interactions.
The company’s customers struggled with existing BC approaches that they perceived
laborious and resource intensive. The first author initiated a DSR project involving our
research group (comprising the first author and two additional researchers), as well as
employees from the IT consultancy as design partners. After initiation, we developed our
problem awareness in meetings with the design partner. They provided feedback on the
practical relevance, while we shared our research knowledge and assessed the research
relevance using prior literature (see Appendix A). Through this we established a shared
problem awareness, which we captured in meta-requirements (MRs) as classes of design
imperatives that describe an artifact’s scope, boundaries, and goals (Arazy et al., 2010; Gregor
& Jones, 2007). These MRs serve as basis for an artifact’s creation and evaluation and ensure
its practical relevance (Lins et al., 2019).
Cycle 1:
Problem Formulation to Meta-requirements
Cycle 2:
Suggestions for the Thrifty BC Management
Approach for SMEs
Cycle 3:
Developing the Thrifty BC Management Approach
Cycle 4:
Evaluating the Thrifty BC Management Approach
Reporting results
Tentative meta-requirements for a BC
management approach for SMEs
Tentative design of three phases with each phase
comprising a set of modules
•
Guiding questions for each module
•
Workshop method for SME self-assessment
•
Efficacy of the Thrifty BC Management
Approach for SMEs
•
Refinement of the tentative meta-requirements
•
Meta-requirements for BC management
approaches for SMEs
•
Thrifty BC Management Approach for SMEs
•
Confessional account of the design process
Cycles in the Design Process for a BC
management approach for SM Es Outputs
In Suggestions for the Thrifty BC Management Approach for SMEs cycle, we created design
alternatives by building on the MRs that materialized the justificatory knowledge gained from
the literature and through the design process (Gregor & Hevner, 2013; Iivari, 2020). In regular
meetings, we suggested the alternatives to the design partner (Kuechler & Vaishnavi, 2008)
and modified them based on their feedback (Gregor & Jones, 2007). This resulted in a
potential design, which required further elaboration (Kuechler & Vaishnavi, 2008).
The Developing the Thrifty BC Management Approach for SMEs cycle focused on elaborating
the potential design through an iterative process, in which we transformed the MRs into
material form, resulting in an approach with three separate phases, each with modules for
relevant BC activities. With the design partner, we developed guiding questions for each
module and advice for executing the approach (see Appendix B).
The Evaluation of the Thrifty BC Management Approach for SMEs cycle comprised a field
study involving five SMEs. Its goal was to evaluate the designed approach against the MRs
and to revise it based on the learnings gained from its evaluations. Table 1 provides details
on our project members and their role in each cycle of the design process.
Table 1. The Design Science Research Project Members and their Role in the Design Process
Role in the Design Process by Cycle
Project Members
Research group:
Robin, a scholar with extensive
experience on BC research; Kim, an
experienced information security
consultant who has conducted
doctoral research on BC and
published several research articles
on the topic; and Alex, an
organizational change management
consultant in the process of doctoral
studies. Prior to the project, we all
had received formal DSR training
from prominent IS DSR scholars, but
none of us had completed a full DSR
research cycle in practice.
Design partners:
One executive (Jude) and two
employees of IT Consultancy with
years of practical experience in
advising SMEs in Information
Security and Business Continuity
Cycle 1:
Problem
Formulation to
Meta-requirements
• Review justificatory knowledge
provided by existing research
(for the details and results of the
review of existing BC literature
see Appendix A)
• Formulation of MRs
• Provide initial problem awareness
• Provide justificatory knowledge
stemming from their observations
and experience of addressed
practical problem
• Sounding for our problem
understanding
Cycle 2:
Suggestions for the
Thrifty BC
Management
Approach for SMEs
• Suggesting design alternatives
• Iteratively develop a BC
management approach for SMEs
• Evaluate our design alternatives
• Provide feedback on design
alternatives
Cycle 3:
Development of the
Thrifty BC
Management
Approach for SMEs
• Developing the design
suggestions to a full-fledged BC
approach
• Assist and contribute on
developing the tentative design
Cycle 4:
Evaluation of the
Thrifty BC
Management
Approach for SMEs
• Evaluate the designed Thrifty BC
Management Approach in a field-
study with SMEs
• Improve artifact design based on
the field-study evaluation
• Report designed artifact
• Facilitate access to IT
Consultancy’s customer SMEs for
evaluation
Data Collection
Throughout the design process, we drew on common recommendations for qualitative
research to collect data on the real-world problem, the artifact’s design, and the design
process. The resulting data set originates from multiple sources but with different foci
depending on the design cycle (see Table 2). Tasked with the artifact’s design, we gained and
produced firsthand knowledge on the Thrifty BC Management Approach’s design. We created
illustrations of the approach and compiled documentations on its design, linking the approach
to existing BC literature. We each kept our own set of design and reflective notes. While design
notes capture suggestions or reasoning for certain design aspects in relation to existing
knowledge, reflective notes discuss the design process, relation to the design partner, and our
problem understanding as well as design activities.
Table 2: Summary of data collection
Design Process Cycle
Data Collection Focus
Main Data Collection Sources
Cycle 1:
Problem Formulation to
Meta-requirements
• Understanding the real-world
problem
• Assessing prior knowledge
• Artifact illustrations and
documentation
• 7 internal meetings in
research group
• 9 meetings with design
partner
• Design and reflective notes
Cycle 2:
Suggestions for the
Thrifty BC Management
Approach for SMEs
• Derive alternative designs from
MRs (i.e., prior knowledge)
• Design partner’s feedback on
tentative designs
Cycle 3:
Developing the Thrifty
BC Management
Approach for SMEs
• Design partner’s expertise in
conducting effective BC
• Existing guidelines for effective
BC
• Emails exchanged with the
design partner and internally
• Literature review (see
Appendix A)
Cycle 4:
Evaluation of the Thrifty
BC Management
Approach for SMEs
• Criteria to assess the designed
Thrifty BC Management
Approach’s efficacy
• Learnings from field-study settings
to improve the artifact’s design
• 2 feedback sessions
• 9 workshops with SMEs
During the first three cycles, meetings with the design partner were an important data source.
We received feedback for our alternative designs from the design partner on whether and how
they address their practical problem. We prepared for these meetings by crafting topics of
interest and concern in relation to the real-world problem. The design partner’s role in these
meetings evolved from providing feedback in the first two cycles to actively engaging in design
activities in the third. We took notes during these meetings instead of audio recordings due to
the sensitivity of the information shared on the design partner’s customers’ BC practices. We
emailed the design partner in between the meetings to give updates on the design process,
to plan for upcoming meetings, and for clarifications, follow-ups, and alternative design
suggestions. We stored these and our internal emails to keep record of the design and its
process.
In the fourth cycle, when evaluating the designed approach, we collected data through
feedback sessions and field-site workshops with SMEs. We discussed with BC or information
security experts after presentations of our Thrifty BC Management Approach to understand
and establish general awareness of the SMEs’ business context. Testing the approach, we
conducted nine workshops with the involved SMEs that we documented as field notes: one
researcher moderated and facilitated the workshops; a second researcher kept notes and
assisted with follow-up questions. We refrained from audio recording the interviews and
workshops for sensitivity.
Data Analysis
Data analysis took part during and after completing the design process. During the four design
cycles, we analyzed our notes from internal meetings and meetings with the design partner
for clues on a Thrifty BC Management Approach for SMEs. Since this analysis occurred
spontaneously, we did not systematically code the collected data but studied our notes and
prior literature for hints and recommendations on solving the practical problem.
After completing the design, we analyzed the collected data in order to reconstruct the design
process including design decisions and key learnings from the evaluation following common
recommendations for qualitative data analysis (Miles & Huberman, 1994). For this, we created
an extensive tabulation comprising all events (Miles & Huberman, 1994). Recorded events
include our research group meetings, meetings with the design partner, email conversations
(both among ourselves and with the design partner), interviews, and evaluation workshops
with SMEs. We noted the dates of these events to order them chronologically and studied
each event for its content, for example, who attended, what was discussed, which decisions
were made, or knowledge created on the artifact’s design. We also analyzed our notes for
learnings on the design process and the reflections on the design partner’s role and captured
the results. Table 3 illustrates the resulting tabulation including data excerpts.
Table 3: Excerpt from the tabulation created during analysis
Date
Event
Type
Content Summary
Design Reflection
Process Reflection
Oct 20,
2016
Internal
Meeting
• Robin outlines design
partner's contact,
interest and goal
(what was shared by
the design partner)
• Discussion of the
alleged problem area
• First ideas for
possible solutions
(defining the solution
space)
Approach needs to:
• make SMEs' infra-
structure visible in
order to design BC
for it
• be lean (assumption
that SMEs face
resource scarcity)
• in a first step, create
awareness of BC
• We prepare based on
the information given
by the design partner
(coined our
assumptions and
solution space)
• We note that we
depend on design
partner for testing the
approach
…
Nov
24,
2016
Meeting
with
design
partner
• We presented the
tentative design to the
design partner
• Design partner
claimed that the
tentative solution
• Design partners'
feedback on the
tentative artifact was
• Design partner
provided feedback on
the tentative design
offered little to them.
They stressed the
practical problem as
how to build BC from
a workshop such that
it is resource-efficient
and covers the
necessities
feedback on our
problem
understanding
…
Jan 19,
2017
Meeting
with
design
partner
• Joint workshop with
the design partner to
formulate lists of
possible actions for
BC management in
each module
• Notion of breaking
down modules into
actions for BC
management that
SMEs should
consider per module
• The new design of the
approach builds on
the modules the
design partner
introduced on Dec 16,
2016. They thus
reflected their idea of
the new approach.
…
When outlining each cycle’s findings, we borrow ideas from confessional writing as alternative
genre (Avital et al., 2017), and present our findings as a narrative of our design activities
interlaced with descriptions of the artifact (Schultze, 2000; Van Maanen, 2011). Confessional
writing originates from ethnography and seeks to expose researcher as a “research instrument
[…] rendering their actions, failings, motivations and assumptions open to public scrutiny and
critique” (Schultze, 2000, p. 8). Adopting this genre, we seek to overcome the division between
the neat and mechanistic descriptions that often characterize DSR and the reality of the messy
and precarious process (cf. Schultze, 2000; Van Maanen, 2011), along which research may
proceed in practice. While usually one researcher performs an ethnography, we formed a
research group of three, jointly conducting this DSR project. While a confessionally writing
ethnographer expresses solely their personal experiences, we explicated and discussed our
individual experiences and reflections to find consensus on the design process at the research
group level. Most importantly, we render transparent the context and our choices, concerns,
and reflections that led to the presented artifact but also the hiccups and the contingent parts
in our design process (Burton-Jones et al., 2021; Vom Brocke et al., 2021). Writing
confessionally, we bring forth our role as part of the research apparatus, translating existing
knowledge and practical experience into design knowledge. To divulge the different voices
involved in the design process, we report our design study using pseudonyms for the research
group and the design partners (see Table 1).
1
Designing the Thrifty BC Management Approach
In this section, we present the four cycles of our DSR project as narratives that seek to capture
the artifact-in-the-making rather than merely the artifact. We describe the final artifact and its
use in Appendix B to facilitate practitioners in adapting the artifact for self-assessing and
developing their BC.
2
Cycle 1: Problem Formulation to Meta-requirements
The first cycle of the design process evolved around forming and formulating a common
understanding of the research problem and drafting MRs that could satisfy the identified
problem. Next, we narrate through this process and expose the glitches, hiccups, and
contingencies that characterized our iterative, and occasionally messy, process of the artifact
design.
Getting Set: Clarifying What to Design and How
Our initial discussions with the design partner led us to believe the problem was
straightforward: the current BC management approaches, such as ISO 22301 and the relevant
parts of ISO 27001, COBIT, and ITIL are too laborious to be applicable within the SME context.
We also knew this was an issue that resonated with the BC literature (De Haes et al., 2016;
Devos et al., 2012; Mijnhardt et al., 2016) but had not been satisfactorily solved. In particular,
Jude was concerned that existing approaches stipulate the creation of a significant number of
documents, normative processes, and formal management systems that conflict with SMEs’
1
The use of ‘we’ refers to the research group comprising Robin, Kim and Alex. It excludes the design partner,
i.e., Jude, and the two employees from the IT consultancy.
2
The designed artifact will also be published on a website (after the peer review of the article) to allow artifact
transparency and ongoing development of the artifact based on feedback from practitioners.
way of organizing. For them, this was both a practical and economic problem, as implementing
and selling the existing approaches for their customers was deemed infeasible.
A different picture of the problem progressively started to emerge. Jude saw that, in lieu of
existing BC approaches, what they actually needed was an approach that enables them to
show their clients the potential and significant points of failure. Quoting Jude, “they [the SMEs]
talk about BC problems related to material supply issues and such but fail to realize that their
most critical IT server is placed under a coffee machine” (meeting notes). According to the
design partner, the problem was that their SME clients were “unaware of their dependence on
IT infra” (quote from a slide set). Kim took these considerations as indications that the IT
consultancy did not face issues of unfitting BC approaches but of BC awareness. Awareness
has been extensively studied in the information security context (e.g., Lebek et al., 2014), but
not within the context of BC, despite its ties to embeddedness (Herbane, 2010b) and collective
mindfulness (Butler & Gray, 2006). Seeing that the solution should aim at “building awareness
and consequently mindfulness” (quote from a slide set), Kim and Alex started crafting an
approach.
Butler and Gray’s (2006) seminal work on IT reliability and collective mindfulness affected the
crafting of the approach as it is one of the few IS studies proposing theoretical foundations for
BC (Niemimaa, 2017). While our extensive review of the literature also showed that
mindfulness has been extensively used as an explanatory theory on how organizations
achieve reliability with technologies (Dernbecher & Beck, 2017; Salovaara et al., 2019), these
studies could not directly provide the prescriptive knowledge required for designing an artifact.
Kim and Alex started drafting a tentative solution, consulting Robin for feedback and ideas.
The design of the tentative solution was formed around empowerment (of employees) and
active socialization, which have been found effective for enhancing collective mindfulness
(Sutcliffe et al., 2016). We assumed that these processes of collective mindfulness could be
instilled into an SME through a workshop for facilitating the emergence of traits of collective
mindfulness (Vogus & Sutcliffe, 2012) by enabling integration of expertise and knowledge
across different organizational functions and levels (Kendall et al., 2005), organizing
socialization and discussion around IT infrastructure as an object of interest. Further, these
ideas derived from collective mindfulness connect well with BC management by creating
opportunities for improving workshop participants’ awareness of and commitment to BC (i.e.,
embeddedness (Herbane et al., 2004). Table 4 elaborates the results of this into preliminary
meta-requirements for the artifact.
3
Table 4. Preliminary meta-requirements for tentative solution derived from the processes of collective mindfulness.
Processes of
collective
mindfulness
Explanation of the process
Preliminary meta-requirements for
tentative solution
Preoccupation
with failure
“Operating with a chronic wariness
of the possibility of unexpected
events that may jeopardize safety
by engaging in proactive and
preemptive analysis and
discussion” (Vogus & Sutcliffe,
2007, p. 48).
The solution should encourage
organizations to proactively and
preemptively (Herbane, 2010b) attend to
analyzing and understanding potential
future sources of contingencies (Gibb &
Buchanan, 2006).
Reluctance to
simplify
interpretations
“Taking deliberate steps to
question assumptions and
received wisdom to create a more
complete and nuanced picture of
ongoing operations” (Vogus &
Sutcliffe, 2007, p. 48).
The solution should facilitate an
understanding and awareness of what
matters organizationally, even when it
conflicts with organizationally accepted
wisdom, e.g., to question the
precedence of material supply over IT
systems and infrastructures for BC.
Sensitivity to
operations
“Ongoing interaction and
information-sharing about the
human and organizational factors
that determine the safety of a
system as a whole” (Vogus &
Sutcliffe, 2007, p. 48).
The solution should facilitate
collaborative and participatory
development of BC (Herbane et al.,
2004; Kendall et al., 2005) through
information sharing and learning to
transgress fragmentation and
boundaries of knowledge to create a
joint view of organizational BC.
Commitment to
resilience
“Developing capabilities to detect,
contain and bounce back from
errors that have already occurred,
but before they worsen and cause
more serious harm” (Vogus &
Sutcliffe, 2007, p. 48).
The solution should not only focus on
past and current incidents but should
aim to facilitate conditions for
participants to collectively improvise in
unexpected situations (Weick et al.,
1999) and develop resilience through
redundancy of resources (Bajgoric,
2006b; Herbane et al., 2004).
Deference to
expertise
“During high-tempo times (i.e.,
when attempting to resolve a
The solution should require that
decision-making on BC-related matters
3
The design process around the workshop-based-approach continued for several weeks until we felt that we
had a suitable solution to be presented for the IT Consultancy. We do not provide a full account of the design of
this first tentative solution but focus only on the aspects relevant for the subsequent design, i.e., on our
interpretation of collective mindfulness in the context of BC management approach.
problem or crisis), decision-making
authority migrates to the person or
people with the most expertise with
the problem at hand, regardless of
their rank” (Vogus & Sutcliffe,
2007, p. 48).
is founded on expertise (Niemimaa,
2015a) rather than hierarchical position.
The expertise should not only include
BC-related domain-specific expertise but
also, e.g., business or work practice
expertise.
To present our tentative solution, Robin organized an online meeting with the design partner’s
three representatives. However, despite our best efforts to understand the problem upfront
and propose a solution that to us aligned with design partner’s experiences, our solution was
ill-received and did not resonate with their expectations. In hindsight, we realized more active
communication with the design partner would have made sense.
In contrast to our expectations, Jude commented with annoyance that they know how to run
workshops and that awareness is a nice idea but would not result in palpable and concrete
outcomes that they viewed as necessary conditions to demonstrate the value of the approach
for their customers, thereby providing justification for the monetary compensation of their
services. Kim pointed out that the design partner had wanted a generic approach to SMEs’
BC but now it felt that the approach should be specifically tailored for them to provide BC
management to SMEs as a service. Jude started claiming that there should be no difference
whether BC management is implemented in-house or with an external service provider such
as IT Consultancy. What he had missed was Kim’s point that BC may engender a conflict of
interest if provided by an IT service provider (as in the case of IT Consultancy). For instance,
for SMEs’ BC it makes sense to acquire IT services from several companies to ensure
redundancy, but business-wise it would make little sense for IT Consultancy to recommend
such redundancy to their customers. Nevertheless, Kim decided to acquiesce to Jude in an
effort to not engender further conflict with the design partner.
Reconsidering Theories as Meta-requirements
During our post-meeting reflections, we all felt frustration and disappointment towards the
design partner, who seemed to have little interest in revising his expectations. In this moment
of frustration, Kim expressed a view that had developed within her. The design partner was
into this project to get a “scientific” stamp on the BC approach, which would make sense for
them marketing-wise, but they were looking to get the stamp without going through all the
research effort required. The effort was clearly much more than what they seemed to have
accustomed to. Kim’s view resonated well with Robin and Alex, leading the project to a
precarious state, raising the question of what should be done next.
We agreed to clarify and explicate our perception of the practical problem and communicate
it cogently to the design partner. What we had missed in the heat of the design was how we
all had little experience in joint DSR projects and thus our expectations of the design partner’s
methodological understanding of requirements for a rigorous DSR project were likely
overstated. Indeed, we already had a misunderstanding at the project’s beginning when we
explained the need to evaluate the BC approach with their customers to be in accordance with
DSR guidelines. To our surprise, Jude seemed hesitant and reluctant to agree to such
evaluations. Later, we learned that Jude thought we intended to test some of the existing BC
approaches to understand how they fail in the context of SMEs. Understandably, this caused
significant concerns for Jude on how amateurish we might seem to their customers but, even
more so, what damage such failures might inflict to their existing customer relations.
After discussions with Robin, Kim emailed Jude and explained that we understand the
practical problem as twofold: (1) there is a lack of awareness; and (2) “SMEs perceive the
current approaches as too heavy”. Further, we clarified some methodological aspects of DSR,
making sure we shared an understanding on the evaluation of the artifact. Finally, Jude
seemed to agree not only with our problem definition but also agreed to provide us SMEs for
evaluating our solution.
From Kim’s initiative, we felt that it was not possible to proceed with mere incremental changes
to the tentative solution but that it was imperative to reconsider and refine our fundamental
assumptions about its design. After all, while design is grounded on practical problems
(Hevner, 2007), it is also founded on theory (Gregor & Hevner, 2013; Gregor & Jones, 2007),
which holds certain assumptions that foreground some aspects of the design while eclipsing
others (Iivari, 2020; Iivari & Kuutti, 2017). These reflections led us to reconsider the descriptive
theories in our design.
Our earlier design decision to center the approach on awareness had also meant that our
focus was almost solely grounded on the “social” aspects of BC (Butler & Gray, 2006), leaving
out a key insight from the literature on the socio-technical nature of BC. This focus was
reinforced by the fact that despite the frequent references to socio-technical phenomena in
the BC literature (Herbane et al., 2004; Niemimaa, 2015a), we had no prior examples that
have explicated its actual implementation in BC approaches. Turning to the literature on socio-
technical systems, we identified joint development of the social and the technical, and inclusive
decision-making as the theory’s key premises (Bostrom & Heinen, 1977; Mumford, 2006).
While the joint development turned our attention to account for the technical improvements in
addition to the social, the collective and participatory effort guided us to design an artifact that
is both inclusive of the employees and emphasizes collaboration and participation rather than
designing an artifact to be used solely by the IS managers alone. While we operationalized
these theoretical insights as meta-requirements for the artifact, the generic theories provided
us little in terms of the actual substance of BC. We still needed specific MRs to define the
artifact’s objectives, that is, what BC management approaches for SMEs should achieve.
Crafting Business Continuity Meta-requirements
Developing the MRs, we integrated the fragmented BC literature (Niemimaa, 2015b) into
coherent requirements adapted for SME context. Robin took the lead to develop the
requirements while others in the research team joined in by suggesting additions. We also
took advantage of ad hoc prototyping during workshops with the design partner. Thus, the
MRs and crafting the artifact were reciprocally related. The MRs were written as explicit and
imperative statements and took their final form only after several iterations of revisions a
posterior to the actual artifact design.
4
Next, we present the MRs and anchor them into related
justificatory knowledge.
Despite the reaction to our tentative solution, the importance of increasing both organizational
members’ awareness of and commitment to BC (“embeddedness”) (Herbane, Elliott, & Swartz,
2004; Niemimaa, 2015a) was jointly perceived as a requirement for the artifact. We kept this
basic premise of our tentative solution and formulated it as an MR1:
MR1: Facilitate Embeddedness: Commitment to and awareness of BC should develop within
the SME.
Scholars have emphasized that one size does not fit all organizations (Sullivan-Taylor &
Branicki, 2011) and accounting for the context when planning BC measures is significant
(Halonen & Koutonen, 2010; ISO, 2012; Lindström, Samuelsson, et al., 2010). Botha and von
Solms (2004) argue that the size of the organization is a significant contextual factor. During
the workshops, the design partner also highlighted the importance of accounting for SMEs’
existing BC measures and resources (see also Gibb & Buchanan, 2006; Tracey et al., 2017).
BC does not depend only on the use of new or additional technologies (Bajgoric, 2014) but
can also benefit from the use of existing technologies and resources differently (for example
positioning the IT server elsewhere than under a coffee machine). We formulated MR2 as:
MR2: Pay attention to context: BC measures should be sensitive to the specificities of a
particular SME and its existing BC preparedness.
BC literature suggests that BC management approaches should be iterative (Geelen-Baass &
Johnstone, 2008; ISO, 2012; Shropshire et al., 2009) to ensure continuous development
similar to management systems (ISO, 2012). The iterating continuous nature of BC, instead
of being a one-time event, is also well-established among practitioners (Hiles, 2017). As Gibb
4
Some of this development took place during the journal revision process. We would like to thank the
anonymous reviewers for their critical comments and review efforts that pushed us to clarify and improve the
formulation of the MRs.
and Buchanan (2006) state, BC has to be maintained as accurate and up-to-date since the
organization’s risk environment might change. Occasionally, strategic changes of business
models necessitate significant re-evaluation of the whole organizational BC (Niemimaa et al.,
2019). With the support of the scholarly and practitioner literature, we defined MR3:
MR3: Maintain accuracy: BC measures should be maintained as up-to-date and accurate.
Our discussion with the design partner led us to conclude that the BC management should
not be a “big bang” approach but one that should be developed gradually. We also found
support for this requirement from the literature in the form of a maturity model for BC
(Lindström, Samuelsson, et al., 2010), and as a cyclic approach (Botha & Von Solms, 2004).
Such a gradual process allows SMEs to stretch resource use over time by first preparing for
incidents that threaten the most critical business process(es) and gradually develop the BC
management of the same or other processes (Botha & Von Solms, 2004; Reuter, 2015;
Tammineedi, 2010). Thus, while the gradual development does not necessarily save SMEs
resources, a BC approach should help the SMEs to prioritize and stretch the development
over time. Hence, we defined MR4 as:
MR4: Develop gradually: BC measures should be developed gradually over time and based
on the importance to consider SMEs’ financial and other realities.
A low degree of formalism (e.g., low organizational structure, informal roles/responsibilities,
lack of formal documentation, and planning) is a typical trait of the SMEs (Herbane, 2019;
Vargo & Seville, 2011). BC approaches for SMEs should avoid imposing extensive
documentation requirements, which can increase bureaucracy and formalism, straining SMEs’
resources (Herbane, 2019). Further, the extensive documentation required by some of the
current BC approaches (Freestone & Lee, 2008; Gibb & Buchanan, 2006) may not be sensible
and meaningful within SMEs’ context. Thus, we defined MR5 as:
MR5: Minimize documentation: Documentation should be kept at essential minimum.
SMEs rarely have access to the domain-specific expertise required for BC management
(Freestone & Lee, 2008; Niemimaa & Niemimaa, 2019) because of their insularity from niche
expertise (Chen et al., 2007) and lack of financial resources to acquire them (Bilili & Raymond,
1993; Kinnunen & Siponen, 2018). During a workshop, Jude suggested the SMEs should be
able to use the artifact alone or with the support of their consultants and the artifact could
present a “baseline” for BC (i.e., recommended minimum measures to be implemented). This
idea of a baseline connected well with the requirement that the artifact needs to provide SMEs
with detailed guidance to self-assess, plan, and implement BC measures (Hendela et al.,
2017; Shropshire et al., 2009; Sullivan-Taylor & Branicki, 2011). We defined MR6 as:
MR6: Enable self-assessment and development: Guidance for the BC approach should be
detailed enough for SMEs’ independent self-assessment and development of their BC.
Reflecting our learning during the design, the practitioners’ experience, and the prior literature,
we came to realize that the BC approach should consider both the social and the technical
aspects of BC. Accordingly, we defined MR7 as:
MR7: Develop jointly the social and the technical: Both the social and technical aspects of
organizing should be developed.
Participatory development of BC enables integration of knowledge across organizational
boundaries and combination of substance matter expertise. Participatory development,
traditionally including democratic decision making, has been recognized also as a key aspect
of the socio-technical perspective (Mumford, 2006). In the BC context, participation requires
that employees are actively engaged rather than mere informational sources for the planning
process (e.g., Devargas, 1999). The requirement for participatory development also became
apparent through our empirical observations, as Kim was invited to attend a workshop the
design partner had organized to show how they work with their customers in a participatory
manner. We thus defined MR8 as:
MR8: Facilitate collective and participatory development: Develop BC as a collective
organizational effort by involving employees and managers.
While the socio-technical perspective emphasizes participation, from mindfulness theory we
had learned that high-reliability organizations base their decisions on expertise rather than on,
for example, hierarchy (Weick et al., 1999). Further, hierarchical decision making is
depreciated since those with the domain-specific knowledge do not necessarily hold a high
hierarchical position. We formulated the following MR9:
MR9 Revere substance expertise: Base the BC decisions on expertise (rather than on
hierarchy).
Both literature on BC and theory on collective mindfulness underline the necessity of forward-
looking preparations. While learning after incidents can be valuable (Lindström, Harnesk, et
al., 2010), scholars and practitioners agree on the importance of making a priori preparations.
Such an attitude was also echoed by Jude, and the requirement for proactivity had been one
of the key catalysts of this design project. We defined MR10 as the following:
MR10: Attend proactively: Ensure BC measures are developed proactively prior to incidents.
In Figure 2 we summarize the resulting ten MRs derived from literature and from our interaction
with the design partner to create a BC management approach for SMEs.
Figure 2. Meta-requirements (MR1-MR10) for a BC management approach for SMEs.
Comparing Meta-requirements to Prior Literature and Approaches
After formulating the meta-requirements, we analyzed the existing BC management
approaches on whether they already fulfill the MRs. Our analysis showed that existing
approaches fulfilled seven MRs at most (Järveläinen (2016), Lindström et al. (2010),
Nosworthy (2000), Gibb and Buchanan (2006) and Iyer & Bandyopadhyay (2000)), but none
met all the MRs (see Appendix A, Table A1 for detailed comparison of prior literature and
MRs). The MRs derived from SMEs’ constraints (MR4 ‘Develop gradually,’ MR5 ‘Minimize
documentation,’ MR6 ‘Enable self-assessment and improvement’) were rare in the literature,
whereas MR7 ‘Develop jointly the social and the technical’ and MR8 ‘Facilitate collective and
participatory development’ derived from kernel theories were more frequently fulfilled.
Our analysis confirmed that SMEs should be considered more carefully in BC approaches.
Many studies emphasized comprehensiveness (e.g., Cerullo & Cerullo, 2004; Harris &
Grimaila, 2008; Sambo & Bankole, 2016) or firm-wide implementation (Arduini & Morabito,
2010; Merhout & Havelka, 2008; Wan et al., 2009), which contradicted our idea of a resource-
considerate BC management approach for SMEs. Furthermore, some articles mentioned that
current approaches did not suit SMEs, since small businesses require cost-effectiveness
(Cumbie, 2007) or small businesses do not have crisis management teams or centers (Bell &
Gomez, 2011). Further, we observed that the earlier approaches were largely atheoretical.
Based on these observations, we concluded that designing a BC management approach for
SMEs can make meaningful practical and research impact.
Cycle 2: Suggestions for the Thrifty BC Management Approach
After the first cycle that resulted in a set of MRs, the focus was on jointly brainstorming a new
BC management approach for SMEs that we coined as ‘Thrifty BC Management Approach for
SMEs.’ Next, we narrate through this process of design resulting in an approach with three
high-level phases, each phase having several modules.
From Meta-requirements to a Tentative Solution
Alex consulted existing approaches for inspiration. Comparing multiple approaches, she
concluded that while they differ in many respects, they share some components and parts,
and that these could be considered as a ‘baseline’ for a new approach. She sketched a cyclic
process, which started with a baseline—including mandatory components—and that could be
gradually extended with modules to build SMEs’ BC management. In a joint discussion, Kim
and Robin considered the new design suggestion a leap into the right direction. Robin
contacted Jude to agree on a new meeting to discuss the new design.
In the meeting, Jude seemed very fond of the ‘baseline’ of modules and of the cyclic process
with different phases and modules. He promptly started drawing rectangles as a form of ad
hoc prototyping. These rectangles were placed into a cyclic process that contained titles of
mandatory and optional BC measures such that “each phase would have modules consisting
of actions, which address certain BC issues” (quotation from meeting notes). We realized later
that this form of process-like arrangement of phases and modules also matched well with their
way of working with their customers. Robin proposed that Jude share the drawing portraying
the modules he considered mandatory and optional so that we could take over the design
again and prepare suggestions for organizing these modules in phases.
Three Phases of BC Management: Map-it, Design-it, Continue-it
Alex sat down and reorganized the modules. First, she reviewed the MR and Jude’s drawing,
and told Robin and Kim to merge similar modules. Second, considering MR4, she found
inspiration in the Plan-Do-Check-Act cycle (ISO, 2012) and outlined three phases, Map-it,
Design-it, and Continue-it (see Figure 3). Afterwards, she allocated the modules to these three
phases. Further, in our internal meeting, we sat down to discuss the different modules’
definitions. We intended to concisely describe each module’s content and goal to sharpen
their presentation by reducing ambiguities or overlaps. We continued this design activity in our
next face-to-face meeting with the design partner. In addition, we asked Jude and his
colleagues to suggest concrete socio-technical development measures for each module to
provide actionable recommendations to SMEs in a short action plan (MR5).
Figure 3. Process and modules of the Thrifty BC Management Approach
Design-it
Process Recovery
Management I nfrastructure Resilience
Contingency Planning Critical Premi ses & Facilities
Backup Mana gement Insurance Prote ction
Essential Inform ation
Security Fun ction
Map-it
Environmental/E xternal
Requirements M apping Critical Infrastru cture
Mapping
Critical Data & Application
Mapping
Critical Busin ess Process
Mapping Risk Analysis
Co ntinue -it
BC Manage ment BC Supplier Man agement
Crisis Mana gement External & Inte rnal
Communicati on Management
Co nti nue an d m onito r
de signe d B C m ea sure s
For the first phase—Map-it—we decided to include modules that focus on mapping SMEs’
context (MR2), facilitating embeddedness, and building awareness about their environment
(MR1). The phase starts with establishing the current environment and continues identifying
SMEs’ most critical business processes. Considering gradual development (MR4), we devised
the idea that the SME should choose one of these for closer examination to also incorporate
operational sensitivity (MR2) and an awareness-inducing (MR1) atmosphere. In the
subsequent examination, the critical partners (e.g., outsourcing partners) (Järveläinen, 2012),
data, applications, and infrastructure supporting the chosen critical business process and the
risks for all of these are investigated. We agreed that a thorough analysis of the environment
regardless of whether some parts of it are outsourced or not, is an essential starting point.
Other critical business processes can be included iteratively to extend the scope of BC
management and thereby to gradually develop BC (MR4). Table 5 describes the modules in
the Map-it phase.
Table 5. Modules and their descriptions in Map-it phase.
Module name
Description
Prior literature support
Environment/
External
Requirements
Mapping
Documentation of critical partners, their
contact persons, and how they support
the organization's critical business
processes.
External requirements from law,
suppliers, and partners are often
drivers for business continuity
initiatives (Järveläinen, 2013)
Critical Business
Process
Mapping
Identification and mapping of an
organization's critical business
processes including the information
(systems) these processes use, people
involved as well as interfaces to other
processes, suppliers, or customers.
Choosing one process for further study.
Analyzing the key business
processes is essential in many BC
approaches (Gibb & Buchanan,
2006; Winkler et al., 2010) and value
chain analysis is recommended
(Arduini & Morabito, 2010) to prepare
for impacts elsewhere in business.
Critical Data &
Application
Mapping
Mapping the critical business data and
applications supporting the chosen
process and the business processes
relying on these applications.
Furthermore, recording who is
responsible for these applications.
Determining connections of the
business process to technology, i.e.,
data and applications, is the goal of
IS-focused BC (Baham et al., 2017).
Critical
Infrastructure
Mapping
Mapping an organization's infrastructure
(e.g., application servers, Internet
connection, power supply) essential for
operating the critical business process.
Additionally, ascertaining information
about these infrastructure components
and their operation.
Determining connections of the
business process to technology, i.e.,
infrastructure, is the goal of IS-
focused BC (Baham et al., 2017).
Risk Analysis
Identification of potential risks for the
data, application, and infrastructure;
Identifying possible risks and their
impacts are essential parts in many
assessment of their potential business
impact; definition of adequate risk
treatment (avoid, mitigate, transfer), and
documentation of the results.
BC approaches (Tammineedi, 2010;
Wan, 2009)
For the second phase—Design-it—we included modules that craft an action plan for SMEs to
develop their preparedness, by embedding the BC into the organization (MR1). We observed
that existing approaches usually have design and development steps (Cerullo & Cerullo, 2004;
Iyer & Bandyopadhyay, 2000; Lindström, Samuelsson, et al., 2010). The action plan was
intended to push SMEs to perform the Do-stage from the Plan-Do-Check-Act process (Fani &
Subriadi, 2019; Idrees et al., 2019; ISO, 2012), that is, the implementation of the designed BC
measures with minimal documentation (MR5). We thus define the action plan as an executable
summary that captures the concrete BC measures that an SME designs during this phase
rather than abstract definitions of what a measure should achieve. Table 6 describes the
modules of the Design-it phase.
Table 6. Modules and their descriptions with literature support on Design-it phase.
Module name
Description
Prior literature support
Process
Recovery
Management
Definition of recovery plans for critical
business process including time goals
for their recovery
Recovery time/point objectives as well
as minimum tolerable period of
disruption are common in BCM
(Ahmad, Hadgkiss, & Ruighaver, 2012;
Bajgoric, 2014; Tammineedi, 2010)
Contingency
planning
In order to sustain a minimum level of
business operation, this module
contains actions that should be taken to
define alternative processes and
procedures enabling an organization to
continue their business at a minimum in
the event of disruption.
Redundancy in business processes
offer contingency (Ahmad et al., 2012;
Peterson, 2009).
Backup
management
Definition of processes dealing with the
creation of backups and their
restoration.
Basic continuity process includes
backups (Botha & Von Solms, 2004;
Turetken, 2008)
Essential
Information
Security
Functions
Implementation of essential information
security functions to protect the
business from both information security
incidents and business disruptions
caused by such incidents.
Information security is one possible
threat to continuity (Cerullo & Cerullo,
2004; Lindström, Samuelsson, et al.,
2010)
Infrastructure
Resilience
Contains measures/actions and
guidelines to increase an organization's
infrastructure resilience.
Infrastructure failures are common
reasons for continuity disruptions
(Sakurai & Kokuryo, 2014) and
therefore technological focus of BCM is
popular (Niemimaa, 2015a)
Critical premises
and facilities
Guidelines and possible measures/
actions for organizations to develop
their facilities' preparedness for
business disruptions caused by an
event affecting these facilities.
Pitt and Goyal (2004) remind that
critical facilities and premises should
also be protected by BC.
Insurance
Protection
Definition of possible measures/actions
to successfully transfer identified risks
and their potential (financial) impact to
insurances.
Transferring risk is, along mitigation
and absorbing of risk, a basic risk
management strategy (e.g., Altman,
2006; Gibb & Buchanan, 2006)
For the third phase—Continue-it—we chose to focus on managing BC in the future with a
proactive orientation (MR10). Its modules center on the defined action plan’s implementation
and its operation, evaluation, and gradual development. Our plan was to encapsulate the idea
of maintaining accuracy (MR3) to this phase, because it stresses the importance of monitoring
BC and gradually developing BC management with the help of three trigger points: gradual
development, re-evaluation, and major update. We discussed with Jude how these trigger
points initiate consecutive cycles of the Thrifty BC Management Approach.
Alex first considered re-evaluation triggers comprising operational changes in SMEs’ IT or
business environment that require partial updating of the existing BC action plan. For example,
if key personnel changes, only the communication management may require a re-evaluation
and update. Other examples for re-evaluation triggers are new ISs, changes in key suppliers
or changes in a sub-process (see also Appendix B, Table B4). We thought that if this trigger
point occurs, SMEs should re-iterate the Design-it and Continue-it phases for the affected
processes and respective BC measures.
However, Kim understood that major updates should have trigger points too. Sometimes
SMEs have significant changes that require a new mapping of their crucial business processes
and subsequent design of a BC action plan (e.g., merger and acquisitions, new product,
switching from proprietary software to cloud computing). In case of a major update trigger,
SMEs should conduct the entire cycle for the affected processes.
Then Robin proposed a third trigger point, gradual development triggers. Besides the most
crucial business process, additional processes present gradual development triggers that
initiate consecutive cycles of the Map-it, Design-it, and Continue-it phase. However, we later
noticed in the evaluations that having several critical processes is likely to be rather
uncommon, especially among the smaller SMEs.
Organizations should define which events are relevant trigger points for maintaining and
updating their BC management using this classification of trigger points. Defining business
context-specific events using this classification supports the contextual development of BC
management (MR2). In Figure 4, we present a tentative implementation sequence for different
trigger points. Discussing possible trigger points pre-emptively, the company representatives
become aware that the approach is cyclical and requires gradual development, continuous
maintenance or even updating depending on the respective trigger point (MR3 and MR4). In
contrast to prior literature’s recommendation of time-based maintenance of BCM (e.g., annual
or bi-annual updating on an extensive level) (Botha & Von Solms, 2004; ISO, 2012), we
consider these trigger points to introduce need-based maintenance (MR3). They turn the BC
action plan into a living rather than a static document.
Figure 4. The Thrifty BC Management Approach implementation sequence with gradual development, re-
evaluation, and major update trigger points.
Continue-it
Re-evalu ate Triggers: In itiate iteration of Design -
it and Continue-i t for affected processes
Major Update Trigge rs: Initiate n ew mappin g of
busine ss processe s.
Gradua l Developm ent Triggers: In itiate desig n of
BC me asures for ad ditional b usiness pro cesses
Further, we added the modules of crisis and communication management to this phase as the
reactive measures taken during a business disruption fall into this phase. Since SMEs
outsource IT services, they also need to consider and manage outsourcing risks for BC. This
is addressed in the BC Supplier Management module. Table 7 describes the Continue-it
phase’s modules.
Table 7. Modules and their descriptions connected to prior literature.
Module name
Description
Prior literature support
Crisis
Management
Appointing a crisis management team
and defining each members’
responsibilities in the event of a crisis
Crisis team is often recommended in
prior literature (Pinta, 2011;
Tammineedi, 2010)
External and
Internal
Communication
Management
Definition of rules and guidelines for
both internal and external
communication in case of a business
disruption
In crisis situation, both internal and
external communication is important
(Bell & Gomez, 2011; Braun & Martz,
2007)
BC
Management
Definition and implementation of
measurements and controls monitoring
the performance and effectiveness of
business continuity measures as well
as identification of trigger points for re-
evaluation of BC measures
Prior literature recommends updating
the BCP in regular time intervals (Gibb
& Buchanan, 2006; Lindström,
Samuelsson, et al., 2010).
BC Supplier
Management
Definition of requirements that partners
supporting critical business processes
must fulfill (e.g., their own BC
measures, provision of a contact
person, etc.)
BC has to be considered also in inter-
organizational IS relationships
according to prior literature
(Järveläinen, 2012)
Cycle 3: Refining the Thrifty BC Management Approach
While we had defined the abstract phases and modules, the Thrifty BC Management Approach
lacked, clear instructions for SMEs to self-assess and develop their BC (MR6). Next, we
narrate the development of guiding questions and workshop guidelines for implementing the
BC management.
Formulating Guiding Questions
In our research group meeting, Robin noted that the tentative solution provides little guidance
for SME self-assessment and BC development BC (MR6). Alex came up with the idea that we
could translate the descriptions of measures into questions. Questions would provoke SMEs
to think their BC in relation to their own context and determine whether they require a specific
module and its BC measures (or not). Alex argued that instead of defining backups as one BC
measure, the BC approach should ask whether a business process requires backups for its
continuity. Respective questions would foreground the contextual need rather than providing
a list of means. Alex and Robin started translating BC measures into guiding questions and
tabulated these questions in relation to the three phases and their modules in a spreadsheet.
Robin organized two workshops to jointly develop the questions. Jude attended physically
while his colleagues joined the workshop virtually. For the first workshop, Jude had prepared
a presentation of suggested measures and questions. During the workshops, Robin screen-
shared the spreadsheet with the guiding questions, allowing us to gather feedback from our
design partner and adjust the questions as needs arose. Afterwards, Alex submitted edits of
each module’s measures and the respective questions to Robin, and once they were
complete, we presented the BC approach, including all its modules, measures, and guiding
questions, to Jude. Exemplarily, we illustrate the content for the ‘Critical Business Process
Mapping’ module.
The ‘Critical Business Process Mapping’ module comprises three goals (see Table 5). Alex
and Robin defined Goal A, suggesting that BC management should start with identifying
critical business processes. However, Robin, observing one of our design partner’s client
workshops, noticed that this client’s business processes built on pivotal sub-functions. Thus,
she extended Goal A to also identify “the different functions performed in these processes.”
To facilitate SMEs in achieving Goal A, we formulated the guiding questions no. 1–2.
Considering MR4, Alex put forth that once SMEs had identified their critical business
processes, they should further prioritize these by business impact in case of a disruption
(Järveläinen, 2012; Wang et al., 2010). We captured this notion in Goal B: ‘Choose the most
critical process for further examination’ and guiding question no. 3.
Robin, drawing on Arduinini and Morabito’s (2010) value chain analysis and external service
provider effects for BC (Järveläinen, 2012), argued that SMEs should also map critical
interfaces that can cause potential BC issues. This corroborated with Kim and Alex’s learning
from the design partner’s client workshop, because the respective client often seemed to have
little knowledge about important supplier processes and their BC state. We thus formulated
Goal C: ‘Identify interfaces to other processes, stakeholders, and responsibilities (process
owner)’ and the guiding questions no. 4–7. Table 8 illustrates the ‘Critical Business Process
Mapping’ module with its goals as well as the respective guiding questions. After agreeing on
each modules’ goals and guiding questions, we all felt the approach was ready for evaluation
with the design partner’s clients.
Table 8. Exemplary module with goals and guiding questions to define BC measures for accomplishing these goals
Module–Goals of the module
Guiding questions
Critical Business Process
Mapping
Goal A: Identify critical business
processes and the different
functions performed in these
processes
1. What are the most critical business processes, without
which your business would not survive? A disruption of
which business process would immediately (in 2 hours, 1
day, after 1 day, etc.) terminate your business?
2. What are the key functions in this critical business
process?
Goal B: Choose the most critical
process for further examination
3. Which processes are customer-facing processes (if critical
to the company)?
Goal C: Identify interfaces to
other processes, stakeholders,
and responsibilities (process
owner)
4. Which other processes might be affected if this critical
business process (function) is disrupted?
5. Who is responsible for this critical business process
(process owner)?
6. Is this critical business process supported or used by any
external party (supplier/customer)?
7. On which of your premises is this process performed?
Trialing the Approach in Practice
Before testing the approach with the design partner’s customers, we conducted table-top
testing to assess its applicability in a workshop setting. Kim had ethnographically studied an
SME’s business continuity for several months and we decided to leverage her knowledge to
simulate our approach. We sat in a meeting room with Robin and Alex posing questions to
Kim on the SME’s business processes and IT infrastructure. Running through the designed
approach, we yielded three learnings.
First, we noticed that visualizing participants’ answers to the guiding questions facilitates
discussions. Previously, Jude had suggested using their company’s visualization tool, which
Robin and Kim felt to be too simplistic in its level of detail. Alex also found it would impede
interaction because only one person could control the software tool, thus violating MR8.
Similarly, it would complicate self-assessment (MR6) and the resource-consideration because
it ties the approach to a specific software. We decided to use sticky notes as all participants
could then join in visualizing their discussion, that is, make drawings, take notes, and
reorganize or connect them.
Second, we realized that SMEs require further guidance for applying the approach in a
workshop setting. For example, Kim felt that after three hours of mapping, one experiences
fatigue possibly affecting the engagement and results of such mapping. Therefore, Alex
suggested modifying our initial workshop-based design. She pointed out that the design
partner discarded it for focusing on awareness and not for guiding SMEs through a workshop.
Thus, we adopted the initial workshop idea, allocating the three phases to two workshops. The
first focuses on the Map-it phase and lasts approximately 2.5 hours. The second continues
with the Design-it and Continue-it phases over a similar duration.
Third, we reflected who in SMEs should participate in these workshops. Jude recommended
inviting SMEs’ top management for buy-in and employees with the required expertise and
knowledge in the critical business processes and IT operations. Robin and Kim agreed
because several key managers and experts attending these workshops would create BC
awareness (MR1), constitute a collective and participatory effort (MR8), and involve expertise
(MR9). However, we suggest limiting the number of participants for enabling detailed and
engaged discussions towards a concise action plan for BC management.
Cycle 4: Evaluating the Thrifty BC Management Approach for SMEs
The fourth cycle was centered around the evaluation of the developed Thrifty BC Management
Approach. We evaluated the approach with five SMEs through nine workshops. Table 9
summarizes the evaluations done during this cycle. In what follows, we narrate the evaluation
process.
Table 9. Summary of the Thrifty BC Management Approach’s evaluation
Evaluation
environment
Type of
evaluation
Evaluation
scope
Key learnings
Research Group
• Summative
simulation
All phases of
the Thrifty BC
Management
Approach
• Guiding questions are in a meaningful
order
• Guiding questions facilitate a
comprehensive assessment of BC
management
• The content is distributed across the
three phases and modules such that it
supports gradual BC management
Company A
• Finnish power
distributor
• 26 employees
• Naturalistic
and
summative
field study
• One
workshop
Map-it phase
• Document Map-it phase using colored
post-it notes give an arts-and-crafts
appearance
→ More visual tool would be required
instead (mind-map)
• Significant expertise required to map
critical infrastructure
→ Invite IT staff with expertise on critical
infrastructure
Company B
• Finnish IT
service
provider for
healthcare
sector
• 217 employees
• Formative
evaluation
• Open
discussion
All phases of
the Thrifty BC
Management
Approach
• Approach facilitates understanding of
BC management, especially if top
management is involved
→ Continue testing
→ Requires decision-makers in the
discussion
Company C
• Finnish graphic
design
company
• ~10 employees
• Naturalistic
and
summative
field study
• Two
workshops
• Qualitative
interview
All phases of
the Thrifty BC
Management
Approach
• Significant expertise required to map
critical infrastructure
→ Invite IT staff with expertise on critical
infrastructure
• 1.5–2.5 hours were sufficient for Map-it
phase
→ Half-day workshops sufficient for
Map-it phase
Company D
• Finnish
manufacturer
of agricultural
machinery
• 160 employees
• Naturalistic
and
summative
field study
• Three
workshops
All phases of
the Thrifty BC
Management
Approach
• Requires commitment from top
management
→ Introduce the process and intended
schedule in the beginning and
emphasize the meaning of varied
expertise to encourage decision-maker
participation
Company E
• Finnish
marketing
company
• 46 employees
• Naturalistic
and
summative
field study
(self-
assessment)
• Three
workshops
All phases of
the Thrifty BC
Management
Approach
• The concept of critical business process
as something other than a technical
issue is vague
→ Improve the workshop guidance with
definitions and goals of the process
Struggling with the First Evaluation of the Thrifty BC Approach: Company A
During the design process, we had never received a clear and explicit ‘yes’ from Jude for
evaluating the artifact with their customers, but neither had we received a clear ‘no’. We had
suppressed our concerns about the evaluation amidst of more pressing issues during the first
cycles. When the time arrived to agree on the evaluation, Robin approached Jude several
times until he finally informed us that Company A was willing to be a part of the evaluation.
Before evaluation with Company A, Jude made a request to simulate the workshop setting
with them but from the request it also became clear that he was only interested in using their
own information system for running and documenting the workshop with Company A. Kim
compiled a note: “I started feeling unsure whether they had started to exclude us as workshop
organizers and instead put us in the passengers' seat.”
Robin, who shared the concern, contacted Jude to confront the issue, which ignited a heated
email exchange. Jude answered Robin’s email very abruptly: “In my opinion this post-it stuff
is inefficient and we get needed results when we use information systems” (email). This
caused concerns among us on remaining time for us to evaluate the Thrifty BC Management
approach as well as on the evaluation rigor (should Jude run the workshop). Our thinking was
that we should evaluate the approach, modules, workshop, and guiding questions before
handing the approach to practitioners. After several emails, Jude finally agreed that Robin
could facilitate the workshop and that we could use the approach we had designed.
Jude continued to have noticeable concerns on what impact the evaluation might have for
their customer relationship. Only a few hours before the workshop, Jude sent an email to all
workshop participants, stating that the workshop would be somewhat different than what they
had had before but reassured that despite us running the workshop, he would be in the
background ensuring effective documentation to their information system. We were all rather
surprised and puzzled by his message, because we assumed that we finally agreed on the
approach’s design (as described in Cycle 3). Regardless of Jude’s email, we continued into
the workshop, allowing us to finally test the approach in practice.
Our reception at the workshop with Company A was warm and friendly but neither enthusiastic
nor curious. The participants were managers from different business units as we expected
(MR8), but to our surprise, the IT experts were missing (MR9). It was only then that we realized
Company A had already outsourced its IT operations to IT Consultancy. Jude had not invited
any of their own IT experts to the workshop, since he expected they already had all the
necessary information on that front. With the lead of Robin, Kim was able to document
Company A’s critical business functions during the two-hour workshop, which ran smoothly.
Yet, we could not discuss any technical details as Jude felt these could be obtained later
through IT Consultancy, impeding the facilitation of embeddedness among Company A’s
participants (MR1).
After this partially successful workshop, Robin contacted Jude and Company A several times
to organize a second workshop. However, they could not find a mutual date. After half a dozen
emails, she concluded that Company A had no real interest in continuing the process. Several
months later, we learned that a large company had acquired our design partner and that Jude
left the company shortly after. We surmised that this all explained the ‘radio silence’ leading
to the abrupt end of the design partner’s involvement in the DSR project.
Learning Points from the Evaluation: Company A
We derived three learning points out of these conflicts of interest with the design partner. First,
we should have emphasized inviting IT staff with expertise on the IT infrastructure and not
only business managers (MR9). The design partner’s behavior during the workshop in
interrupting questions related to the IT infrastructure hampered the workshop process and
evaluation of the Map-IT phase. It was clear that the design partner considered these
discussions a waste of Company A’s time, because they already had this information.
However, interrupting discussions around the IT infrastructure also meant that the participants
could not develop awareness (MR1) of their environment, which might have revealed weak
spots in their IT infrastructure, and thereby how IT Consultancy operated it.
Second, the workshop process, including the choice of visualization tool, is essential for
creating awareness. To raise awareness (MR1), we intended to include participants from
different organizational levels using a visualization method that invites interaction (MR8). Jude
only invited managerial actors and wanted to continue using their existing system and
approach as before. We found that this approach would not solve the awareness creation
problem raised by the design partner when initially contacting Robin. Our hesitations on using
our research collaboration as a quality stamp re-emerged.
Third, we learned that managing the involved parties’—both researcher and design partners—
expectations toward the shared project, is crucial. While we strived for a rigorous evaluation,
Jude focused on the business relationship with their client. With the artifact’s design
completed, the design partner’s interest in its evaluation and the DSR project faded.
Evaluations with Companies B to E
Although the collaboration with our design partner had ended abruptly, we were able to
continue the evaluation process. While we did consider quitting the whole research project,
we felt we had already made good progress and despite the faced difficulties we had obtained
positive experiences when using the approach.
Unaware of our design project, Company B, an IT service provider for hospitals, approached
Robin to discuss BC. We wanted to seize this opportunity and organized a meeting to discuss
their BC concerns but also present our approach. After a workshop with the company, they
found our approach promising but continuing cooperation became impractical, because
Company B appointed our contact to a new position. Later, the contact person messaged us:
“If you could discuss business continuity matters with our biggest client, I personally would be
very grateful.” This indicates that they considered the designed approach useful.
When the problems in evaluating the approach with Company A emerged, we sought other
potential SMEs and found Company C. In Company C, Kim interviewed the CEO during the
Map-it workshop, and Robin, based on our learnings from Company A, took notes using a
mind-map tool. For the Design-it and Continue-it workshop, the CEO invited two experts to
join (MR8, MR9), because he wanted them to understand the risks and participate in the
design (MR1). In these workshops, we had sufficient time to discuss both the social and
technical details (MR7). Since Company C already had insurance protection, we excluded the
respective module from the assessment (MR2). During the Map-it workshop, we learned that
a detailed mapping of the critical infrastructure requires context-specific knowledge,
highlighting the importance of collective and participatory development (MR8). Shortly after
the workshop, Robin translated the mind-map notes into an action plan containing all three
phases’ relevant information (a document of 4 pages, with 0.5 page for future actions (MR5)).
Later, Robin interviewed Company C’s CEO, who found the process “good, necessary, [and]
reminded us, what kind of issues one should ponder on once in a while” (field note). Further,
the CEO informed us that they had successfully passed a quality audit that included
requirements for good BC practices that had been a precondition for a new customer contract.
Last, based on the created action plan, they had mitigated a potential BC problem (server
breakdown) by replacing a vulnerable technology with a more reliable solution (MR3, MR4).
Company D participated in a cybersecurity research project, so Robin asked whether they
would be interested in evaluating the approach. After agreement, Robin completed all three
phases within six hours in Company D. In the first workshop (Map-it phase), the CEO, IT
manager, and a business unit manager participated and two research assistants took notes
(MR1). After identification of the company’s critical process, the CEO excused himself, leaving
the IT manager to dominate the discussion due to and his technical expertise (MR9). To
Robin’s surprise, only the IT manager showed up to the second and third workshop. The IT
manager showed good awareness and knowledge of the BC risks the company faced, but
seemed ignorant of the fact that he was the only one with access to all the critical IT assets,
and the only one with an understanding of the ‘bigger picture’ of their BC, which made him—
as ‘key person’—their greatest BC risk. While the short time to run the workshop testifies to
the thriftiness of the approach (timewise), it also indicates the importance of having more
participants than only the IT manager. This reinforced our earlier learnings on the importance
of having multiple people in workshops for collaborative learning and creating BC awareness
(MR1, MR7).
In Company E, we evaluated whether SMEs could self-assess their BC using the Thrifty BC
Management Approach (MR6). Robin was in contact with an employee of Company E, who
was also an IS MSc student at her university at that time, and told her about the approach
under design. The employee seized the opportunity of running the workshop with her employer
for data collection. After a short introduction to the approach, the employee of Company E
independently conducted the approach with her employer. She held three workshops that took
approximately six hours in total. Afterwards, Robin collected feedback from the employee, who
said that the participants had difficulties with the concept of “critical business process.” They
seemed to “grasp it often as something technical such as internet” and therefore they had to
“rewind back in the discussion from some technical issue, which had no connection to
anything” (quotes from emails). Company E was able to identify issues in their BC and, later
on, initiated projects to improve their BC measures based on these identified issues. Based
on this evaluation, we improved the workshop process description, especially definitions of its
concepts and goals.
Our summative simulation and field study evaluation of the designed Thrifty BC Management
Approach suggest that the approach is both applicable and functional.
Discussion and Conclusions
Our design process generated three theoretical contributions (Baskerville et al., 2018). First,
we contribute to BC management with ten MRs, which form classes of objectives for BC
management approaches for SMEs. Further, we instantiated these MRs in the Thrifty BC
Management Approach for testifying to their feasibility and usefulness. Second, we contribute
to DSR rigor by introducing and arguing for research transparency through confessional
writing. Third, we reflect our theoretical learnings derived from the application of collective
mindfulness and socio-technical systems when designing the approach.
The Thrifty BC Management Approach is readily applicable for practitioners, for example, IT
or BC managers. The approach aims to facilitate BC development by bringing agility and less
formality to it with guiding questions for self-assessment, minimal documentation and trigger
points to spark further development of BC. Furthermore, the guiding questions, along with the
workshop guidelines in Appendix B, render the Thrifty BC Management Approach accessible
to practitioners.
Meta-requirements and the Thrifty BC Management Approach for SMEs
Our first contribution stems from the ten formulated MRs underpinning a design theory for
thrifty BC in an SME context and their instantiation in the Thrifty BC Management Approach.
While the MRs can serve as classes of design objectives for designing further BC
management approaches for SMEs, the instantiated Thrifty BC Management Approach
illustrates their usefulness for such design tasks and solves the underlying practical problem.
Further, we derived the MRs from the existing knowledge base and practitioner experiences
on BC management, and their instantiation feeds back to BC management literature.
The three phases—Map-it, Design-it, and Continue-it—of the designed approach comprises
similarities with other BC management approaches, which start by setting the scope, that is,
deciding on which business processes BC management should focus on and then assessing
these processes’ business impact in case of a business disruption (Gibb & Buchanan, 2006;
Tjoa et al., 2008; Torabi et al., 2014).
The evaluative field study to assess whether the designed approach solves the underlying
practical problem showed that the artifact supports SMEs in BC management and thus solves
the formulated problem, illustrating its practical impact (Baskerville et al., 2018; Peffers et al.,
2018). Next, we will describe in detail how the designed approach incorporates the ten MRs
and highlights its contribution to the BC management literature.
MR1 (Facilitate Embeddedness) focuses on creating BC awareness. The designed approach
proposes to combine awareness creation and training with planning to facilitate
embeddedness of BC measures to organizational processes (cf. Spears & Barki, 2010),
instead of a separate training phase (e.g., Lindström, Samuelsson, et al., 2010).
MR2 (‘Pay attention to context’) contributes to prior BC literature by being sensitive to SMEs’
existing BC preparedness and designing SMEs’ contextual BC measures 1) by focusing
particularly on the most critical business process (instead of all critical business processes),
2) by allowing SMEs to choose suitable modules based on identified risks allowing them
flexibility in process and documentation, and 3) by considering SMEs’ existing risk
management measures, which they may not have recognized as BC management. Building
on these, the approach saves resources required to design and implement BC measures from
scratch (cf. Gibb & Buchanan, 2006; Pitt & Goyal, 2004; Tracey et al., 2017).
The goal of MR3 (‘Maintain accuracy’) was to update BC measures. The approach encourages
workshop participants to discuss triggers (i.e., gradual, re-evaluating, and major update) for
re-evaluation of BC measures to ensure continuous but thrifty development of BC, in contrast
to periodic updating of BC (e.g., (bi-)annually, etc. (Botha & Von Solms, 2004; ISO, 2012)).
Instead of treating BC management as a one-time project (Gibb & Buchanan, 2006; Lindström,
Samuelsson, et al., 2010), the approach encourages continuous but need-based updating of
BC measures through trigger points that introduce flexibility to BC management. Further, in
contrast to Botha and von Solms (2004), the designed approach does not stipulate a priori
which measures or processes should be implemented but leaves the decision to the local
context (aiding the decision-makers with relevant supportive questions).
MR4 (Develop gradually) stresses the selection of the most critical business process and
extension to further processes in additional iterations. This enables organizations to focus on
the important processes and to thriftily spread resource use over time. The approach builds
BC gradually by 1) gradually implementing the action plan and 2) starting with measures for
the most critical process, which are then extended to the second, third, etc. most critical
process (if needed). However, if some medium-sized company has several critical business
processes, it is possible to gradually develop BC measures also for those.
5
This ensures
reuse, helps in prioritizing resources, and allows for learning from previous cycles. Instead of
implementing BC in a big bang (Gibb & Buchanan, 2006; ISO, 2012), a gradual process
starting with the most critical process and continuing, if necessary, with other processes helps
to prioritize SMEs’ limited resources.
MR5 (Minimize documentation): The designed approach produces a single, short action plan
not requiring any formal template, but focusing on SMEs’ contextual needs to suit the SMEs’
level of formality in their operation (Vargo & Seville, 2011). An action plan lists the selected
critical process(es), actions for developing BC of the critical process(es), and trigger points for
revising the action plan. In contrast, ISO22301 (2012) lists 14 different documents from policy
to management reviews and Botha and von Solms (2004) expect plans for each cycle they
propose.
MR6 (‘Enable self-assessment and development’) prescribes providing detailed guidelines for
BC self-evaluation in SMEs. The approach contributes to prior literature by providing guiding
questions to facilitate practitioners in self-assessing and developing BC, formulated with the
help of practicing BC consultants (see Appendix B), thereby filling the void of BC guidance for
managers (Butler & Gray, 2006). Thus, practitioners can use the approach without external
expertise, which SMEs can find difficult to obtain. Prior BC management literature (Lindström,
Samuelsson, et al., 2010) and existing standards (ISO, 2012) are abstract and require SMEs
to spend resources on BC experts to translate as well as apply these standards (Niemimaa &
Niemimaa, 2017). Prior literature lacked such guidance (cf. Siponen & Willison, 2009) and it
5
The option to extend the BC management to a second critical business process was not evaluated in our field
evaluations, since all companies claimed to have only one critical business process.
renders our artifact transferable to other contexts featuring the same class of problem (Hevner
et al., 2004).
MR7 (‘Develop jointly the social and the technical’): The designed approach evaluates the
technical infrastructure requiring BC measures, but also guides SMEs to select responsible
people for different tasks, to recognize key personnel risks, etc. The approach aims to facilitate
socialization and discussion around SMEs’ IT infrastructure as an object of interest and
provides a practical application of the socio-technical in the context of BC, although there are
examples of developing both social and technical aspects of BC in prior literature (Arduini &
Morabito, 2010; Hendela et al., 2017). Yet, some focus only on technical aspects (Baham et
al., 2017) or emphasize the combination of business and technical measures (Fani & Subriadi,
2019).
MR8 (‘Facilitate collective and participatory development’) aims to ensure that relevant people
are involved in BC development. The designed approach uses workshops involving
participants from different organizational levels and departments to map the environment,
design the BC measures, and decide the action plan. Prior literature often focuses on top
management involvement (Sambo & Bankole, 2016; Sarkar et al., 2017), but sometimes a
multi-functional development team is called for (Järveläinen, 2016), engaging, for example,
legal experts, accountants, etc. (Nosworthy, 2000). The approach presents an instantiation of
collective and participatory development, extending the role of participants (e.g., employees)
from mere informational sources (Haghighi & Torabi, 2019; Idrees et al., 2019) to co-
designers.
MR9 (‘Revere substance expertise’) prescribes the use of expertise-based decision making.
The designed approach encourages the use of various experts who know the context of the
BC development to formulate the BC action plan. While BC expertise is likely to be a rarity
within the SMEs, experts who know intimately the SMEs’ business context should be easily
found within the company. Furthermore, the responsibility for the implementation of the actions
is discussed in the workshop. Similar ideas are visible in prior literature, although the final
decision-maker is expected to be, for example, a BC manager (Tammineedi, 2010) or top
management (Nosworthy, 2000).
MR10 (‘Attend proactively’) requires that BC measures should be developed prior to incidents.
The Thrifty BC Management Approach follows other BC management approaches and prior
BC literature in aiming for proactive BC measure design. Thus, our design provides further
evidence for its importance.
As such, these MRs provide abstract and generalizable imperatives as a form of design theory
(for the full anatomy of the design theory see Appendix C). We have also shown that the
design problem, and the artifact, thereafter, are important for practitioners.
Research Transparency and Rigor through Confessional Practices in DSR
By borrowing from alternative research genres (Avital et al., 2017), we contribute to DSR
transparency (Burton-Jones et al., 2021) by adapting four writing conventions used within the
confessional genre (Schultze, 2000; Van Maanen, 2011). We argue that the confessional
genre can add rigor through research transparency to DSR. Next, we reflect on and discuss
the learnings we gained by applying the writing conventions to our DSR project.
Research Transparency for Design Process Rigor
While scholars have acknowledged the importance of research transparency for DSR (Burton-
Jones et al., 2021; Pratt et al., 2020), much of the discussion on transparency of DSR has
focused on the artifact’s transparency. We, on the other hand, contribute to the transparency
of the design process; transparency of the artifact relates to the practices of publishing the
product of the design, and transparency of the process relates “to the practice of being open
about how a piece of research has been undertaken and its implications.” (Burton-Jones et
al., 2021, p. iii). We thereby align with and respond to authors arguing for greater transparency
when reporting the design process that produced the artifact (Vom Brocke et al., 2021). To
establish the transparency of the artifact, we provide the designed artifact in Appendix B.
Transparent accounts of the design process allow others to see how the artifact materialized.
We argue that such accounts can strengthen the rigor of DSR projects. Indeed, strict
adherence to methodological guidelines or the attempt to align reporting with these
imperatives do not qualify as a necessary or sole condition for rigor (Siponen et al., 2021).
Any real-world design is bound to evolve through moments of contingencies and
happenstances. By rendering transparent these moments of epiphanies, serendipity, dead
ends, and trial and error that went into designing the artifact, researchers create credibility,
authenticity, and trustworthiness of their descriptions (Lincoln & Guba, 1986) and by this,
establish rigor (Hevner et al., 2004; March & Smith, 1995). The confessional genre can help
researchers in achieving this.
We found that, at times, existing DSR methodologies' sequential and structured nature
contradicted the messy and emergent nature of our actual design process. The conflicts of
interest with the design partner and the sudden changes in the design partner’s organization
were some of the unexpected events that impacted and became implicated in the designed
artifact. In lieu of attempting to align dogmatically with the methodological prescriptions to
achieve rigor, we adapted conventions of the confessional genre to reconstruct the process
as we experienced it: murky, messy, and emergent. That is, we argue that these conventions
can enable authors to achieve rigor through transparency rather than seeking for rigor through
obscurity, that is, honestly and truthfully reporting the actions, events, and mistakes as they
occurred rather than seeking ways in which they can be made to fit the steps and cycles of
established guidelines. Thus, we put forth that the confessional genre can be enacted in DSR
to transparently report the design process for establishing process transparency in DSR
research.
Four Confessional Practices for Research Transparency in DSR
Reporting this study, we adapted and extended four conventions of the confessional genre,
which are well-known within the ethnographic community (Schultze, 2000; Van Maanen,
2011), to DSR research as practices for transparently reporting the design process. While
DSR and ethnography certainly have very different goals (i.e., design versus understanding),
they both take place in a real-world setting where oftentimes the researcher has very little or
no control over the exact course of events, as our narratives illustrate. We extend the
confessional conventions of self-revealing writing, presenting different points of view,
interlacing, and naturalness (Schultze, 2000; Van Maanen, 2011) by adapting and
contextualizing them as four practices for transparently reporting the DSR process. We next
present these four practices:
Practice of self-revealing designer(s). Researchers should reveal the details about
themselves as designers of the developed design artifact. This practice requires them to
expose details about themselves, their background, and their prior experience, but also to
report honestly details, which others might view problematic or even as mistakes, that have
influenced the design process (cf. Schultze, 2000; Van Maanen, 2011). To establish this,
researchers may choose to introduce pseudonyms for the different actors and use personal
pronouns. The use of pseudonyms enables the researchers to enact a degree of anonymity
without resorting to abstract and unspecified collectives or passive voice for the façade of
objectivity. Through the practice of self-revealing designer(s), researchers become visible as
designers, as part of the research process and shaping the resulting artifact; research does
not do design, researchers do.
Practice of interlacing design and confession. Researchers should report their design and
confessions in one study. Confessional statements differ from the prescriptive statements on
the design artifact. Yet, instead of reporting the confessional material separately, this second
practice suggests interlacing the confessions relevant to the design process and artifact with
the prescriptive design knowledge (cf. Schultze, 2000). This interlacing illustrates how the
design emerged from the contingencies, trial and error, and unexpected events that
constituted the design process. The interlacing renders visible and salient the omissions and
commissions done spontaneously during the design process. Thus, it facilitates interpreting
the design knowledge and its grounding in prior knowledge and the design process.
Practice of designer-researcher stance. Researchers should expose different points of view
on their design process and design artifact especially when these points of view conflict or tell
different stories. In a DSR study, researchers are also designers, which requires them to shift
between a designer and a researcher stance (cf. Van Maanen, 2011). This practice
accordingly suggests that researchers need to maneuver between their designer and
researcher role, demonstrating that they possess the ability to distance themselves from the
designed solution while being immersed in the abductive search process for this solution
(Gregory & Muntermann, 2014). Researchers render transparent the different interests
underlying the design process and design artifact.
Practice of artless ingenuity. Researchers should illustrate the naturalness of the design
process that produced the designed artifact (cf. Van Maanen, 2011). This means showing that
they developed the design artifact leveraging prior knowledge (including the methodological
guidelines) when addressing the problem space and normalizing the messiness and
contingent conditions of the design process as reflecting the nature of DSR studies in a real-
world setting.
These practices contribute to complementing the existing methodological guidelines for DSR;
not to overthrowing or replacing them. Existing guidelines focus on providing idealizations of
how to conduct DSR (Siponen et al., 2021), but only limited guidance exists on how to present
the DSR process transparently, even if the process is recognized as a key part of the ‘anatomy’
of DSR research (Gregor & Hevner, 2013). The four practices offer researchers guidance to
transparently report how they confronted and dealt with the messiness of their design process
through creative and generative application of existing methodological guidelines for
conducting DSR. As our study serves to testify (Appendix D presents an evaluation of how we
applied these practices against a list of criteria for each practice), these four practices render
transparent the DSR process by dissecting the ideal design process as depicted by
methodology guidelines and the actual design process happening in the real world with all its
contingencies. Thus, as practices for reporting DSR transparently, they extend and
complement existing methodological DSR guidelines.
Implications of DSR Process Transparency through Confessional Practices
The transparency of the design process resulting from these practices contributes to DSR in
four ways. First, transparency of the DSR process allows for reconstruction and evaluation.
We acquiesce to Pratt et al. (2020) that it would be detrimental to extend the notion that
research transparency increases repeatability to all types of research. We argue that this
notion conflicts with the naturalistic, contingent, and emergent nature of DSR and that
transparency must respect the plurality of IS research (Burton-Jones et al., 2021). We posit
that transparency of the DSR process can help our peers to reconstruct and assess the design
process; not to repeat and verify it, but to conceive and evaluate under what circumstances
the design proceeded. Thus, both the researchers themselves and those who need to evaluate
their work can directly benefit from the confessional practices as a way for authors to report
their study transparently and for the reviewers to expect the researchers to do so.
Second, transparency of the DSR process creates accountability. DSR aims to be practically
relevant, seeking to make an impact on the world through design. As Schultze et al. (2020)
argue, “accountability [is] an individual’s liability to give an account of his or her judgment,
actions, and omissions during the research process. To be accountable is to be answerable
for decisions made, actions taken, and effects produced.” (p. 815). Hence, we see that through
transparency of the DSR process, researchers can gain accountability over their design.
Third, transparency of the DSR process serves pedagogical aims. The smorgasbord of DSR
guidelines in journals and conferences “make[s] it difficult and costly to carry out DSR projects”
(Peffers et al., 2018, p. 130) and can be particularly daunting for students and newcomers
who take up the task of a DSR study. We posit that thorough reading of others’ design
struggles can demystify DSR as a methodology and convey the design process reality in lieu
of presenting a hygienic process that portrays a trajectory not unlike the ones in idealized
guidelines. Such transparency illustrates that we become designers by designing, by creating
artifacts in interaction with the field, practitioners, and the real-world problem, and that there
are likely to be as many ways of doing DSR as there are DSR scholars (and DSR projects).
Thus, transparency of the DSR process demystifies the methodology by conveying its
application in a real-world context to students, newcomers, researchers, and reviewers.
Last, transparency of the DSR process can contribute to methodological improvements. While
there are several methodological guidelines available to DSR scholars, we lack the evidence
and the process through which these guidelines were constructed. Indeed, they give accounts
of idealized ways of conducting DSR. Such guidelines have been criticized on the basis that
they lack empirical evidence but also that they do not establish the necessary relationship
between the guidelines and good research (Siponen et al., 2021). Increased transparency of
the process can provide empirically founded descriptions of how the design took place in
practice, which can serve as the basis for empirically founded methodological guidelines and
practices.
In addition to the positive implications, we must also confess pitfalls of the confessional
practices: length versus relevant detail and clear artifact presentation. The required detail to
achieve process transparency can increase the length of a respective DSR report. Since some
journals have strict length limitations, this pitfall poses a challenge for publishing. Through
multiple revisions, we continuously adjusted the level of detail to find a balance between length
versus relevant detail. We do not suggest sacrificing transparency for publishability. Rather,
when writing their accounts of the DSR process, we suggest that authors reflect on what
details are relevant for achieving process transparency by considering whether those details
made a difference on the resulting artifact. Other details to enliven the text can be added, if
space permits.
Our writing practices, particularly the practice of interlacing design and confession, can
explicate the evolutionary nature of the designed artifact. At times, this may entail that the
confessional writing requires the presentation of an intermediate design to add process
transparency. The presentation of multiple design stages, however, impedes a clear artifact
presentation. Addressing this pitfall, we decided to present the artifact’s final design and
complementary descriptions in a single appendix (Appendix B). This allowed us to describe
intermediate design stages to explicate important design decisions and present the artifact’s
final design clearly. We acknowledge that the structure thereof violates the suggested
structure for DSR papers (Gregor & Hevner, 2013), but we deemed it suitable for our particular
research and artifact. Others will need to decide which structure serves their research aims.
Theoretical Learnings on Collective Mindfulness and Socio-Technical
Perspective
The DSR study, besides the practical need it addresses, offered us opportunities for
theoretical learning on the socio-technical perspective, on collective mindfulness, and on their
interrelation in BC (Butler & Gray, 2006; Niemimaa, 2017). After extensive review of the
literature on BC (see Appendix A), we find our study is the first to provide theory-based design
of a BC management approach. While only a small contribution to theory, the theory-based
artifact makes an important contribution to the area of BC to help establish it as a more mature
and rigorous research domain.
The design process and the design artifacts provide three learnings in relation to collective
mindfulness in BC.
First, the DSR project revealed synergies between collective mindfulness and the socio-
technical perspective. MR7 (‘Develop jointly the social and the technical’) and MR8 (‘Facilitate
collective and participatory development’) were influenced by the socio-technical perspective,
but also could have been drawn from the collective mindfulness theory. The socio-technical
perspective has a strong interventionist focus (Mumford, 2006) and thus embodies certain
prescriptions on how development should proceed. Further, it included a strong value stance
during its initial development (Cherns, 1976). BC’s socio-technical nature has been
recognized in past literature (Herbane, 2010b) but has tended to tilt either towards the social
or the technical (Niemimaa, 2015a) and remained largely at the level of abstract statements.
Within the broader socio-technical discussions, participatory development assumes that
employees should be able to participate in discussions concerning changes to their
organization’s technical fabric. We found this particular stance to be insufficient with regard to
BC. Most of the decisions on preparing for the unexpected should not be merely democratic
(non-hierarchical) decisions but founded on expertise, as collective mindfulness argues—
whether the expertise concerns knowledge on BC or more broadly domain- and work-specific
knowledge. Thus, we found the socio-technical and the emphasis of mindfulness on expertise
to provide complementary perspectives in the context of BC.
Second, the design process surfaced consideration between the social and the technical,
especially in the MR7. The processes of collective mindfulness (Table 4) focus on the social
aspect. The design partner’s feedback on the workshop-based approach challenged the
adequacy of collective mindfulness as a basis for our artifact. While the literature has
established that collective mindfulness contributes to reliability of technologies (Butler & Gray,
2006) and that the use of technologies can facilitate and hinder mindfulness (Valorinta, 2009),
we found that the theory tends to fade technical aspects into the background as
inconsequential or at least invisible in themselves and consequential only through social
processes. We realized the detrimental effects such focus could have for organizational
incident preparations, which are a key aspect of any successful BC. Viewing technologies as
inherently and invariably unreliable (Butler & Gray, 2006) overshadows the fact that some
technologies are indeed inherently more reliable than others, which suggests that conscious
and meaningful developments on the organizational technical fabric can contribute to BC
(Bajgoric, 2006a). The insights we derived made us recognize the need to treat the social and
the technical simultaneously as distinct yet interrelated in BC.
Last, we reflect on our learning on the facilitation of collective mindfulness through
interventions (Sutcliffe et al., 2016). Our primary interest was to fulfill the practical needs (i.e.,
to design a BC management approach, which considers SME-specific requirements
emanating from their limited available resources). Accordingly, we did not specifically focus
on measuring or evaluating changes in collective mindfulness. Nevertheless, our observations
and post-design reflections suggest that during the artifact’s evaluation, participants grew
aware of their organizational infrastructure (MR1), shared information across hierarchical
echelon and knowledge-boundaries (MR8), engaged in expertise-driven decision-making
(MR9), and took proactive orientation to incident preparation (MR10); all of which are
characteristics of collective mindfulness. Yet, we observed how limited participation and
insufficient knowledge of the IT infrastructure tended to encourage contemplation and
inactivity, which were visible as participants’ willingness to externalize responsibility (to
external IT partners), revere to expertise, as well as their disinterestedness toward
preparations visible through their “everything is already taken care of” attitude. Obtaining both
business and IT experts simultaneously in a workshop requires top management commitment
on BC. While we have no conclusive evidence on the effects of the artifact on collective
mindfulness, these observations provide further support for existing discussions (Sutcliffe et
al., 2016) and propose that visualizations of the organizational infrastructure can foreground
the “invisible background” (Star & Ruhleder, 1996) and encourage commitment to resilience
and reluctance to simplify interpretations.
Limitations and Future Research
Designing a BC approach, which facilitates expert-based decision making but could be used
independently by SMEs, posed a dilemma between theory and practice. BC requires
substantive expertise, which is rarely available within SMEs and acquiring such resources can
be difficult or even out of their reach. We solved this dilemma, generating guidance for SMEs
to use the artifact independently. However, we acknowledge the risk and problematic nature
of such guidance becoming ‘checklists’ for BC, encouraging mindless ticking off of outlined
actions (Siponen & Willison, 2009). Therefore, we formulated the guidance as supporting
questions, which can, at least partly, inspire reflection and learning among participants,
thereby encouraging mindful use of the provided guidance. Further evaluations offer a starting
point to assess and improve the offered guidance to solve this dilemma.
Further evaluations should also span testing of the designed artifact’s instantiation of MR3
‘Maintain accuracy.’ While we provide justificatory knowledge for MR3, our naturalistic field
evaluation offers little insight into how this MR plays out when using the designed approach.
The nature of the companies that took part in the project limited opportunities for the
evaluation; as small companies, they only had a single critical process. Future research should
look into SMEs with multiple critical processes for evaluating additional cycles of BC
development.
Last, we acknowledge that the evaluations we have conducted span not all possible SME
contexts. The design partner’s involvement created practical expectations and relevance for
the approach within their different clients’ contexts. Based on this, we decided to design a
comprehensive but readily usable approach for these clients’ contexts. We decided to focus
on relevance over rigor. This dichotomy—rigor vs. relevance (Hevner et al., 2004)—became
salient when the artifact’s increased complexity contradicted a systematic evaluation of its
application in various SME contexts. We felt that systematic evaluation would hold back an
artifact that already proved relevant within the assessed SME contexts. Yet, we considered
this emphasis on relevance as acceptable, because future applications of the approach will
continue to inform its design.
Acknowledgements
All authors contributed equally to the paper. We wish to thank our Senior Editor, Professor
Alexander Maedche and the two anonymous reviewers for their constructive comments in the
review process. We also are grateful for professors Mikko Siponen and Hannu Salmela and
Associate Professor Abayomi Baiyere for their comments on the early version of this paper.
Our thanks go also to M.Sc. Atso Aho, who helped us in the project data collection as well as
all Jude from IT consultancy and all companies involved in the evaluation. The research
project was partly funded by European regional development fund (1732/31/2015).
References
Adler, P. S., & Kwon, S. W. (2002). Social capital: Prospects for a new concept. Academy of
Management Review. Academy of Management.
Ahmad, A., Hadgkiss, J., & Ruighaver, A. B. (2012). Incident response teams – Challenges in
supporting the organisational security function. Computers & Security, 31(5), 643–652.
Altman, W. (2006). When it all comes raining down [business continuity planning]. Engineering
Management, 16(1), 46–48.
Arazy, O., Kumar, N., & Shapira, B. (2010). A theory-driven design framework for social
recommender systems. Journal of the Association for Information Systems, 11(9), 455–
490.
Arduini, F., & Morabito, V. (2010). Business Continuity and the Banking Industry.
Communications of the ACM, 53(3), 121–125.
Avital, M., Mathiassen, L., & Schultze, U. (2017). Alternative genres in information systems
research. European Journal of Information Systems, 26(3), 240–247.
Backhouse, J., Hsu, C. W., & Silva, L. (2006). Circuits of Power in Creating De Jure Standards:
Shaping an International Information Systems Security Standard. MIS Quarterly, 30,
413–438.
Baham, C., Calderon, A., & Hirschheim, R. (2017). Applying a Layered Framework to Disaster
Recovery. Communications of the Association for Information Systems, 40, 12.
Bajgoric, N. (2006a). Information systems for e-business continuance: A systems approach.
Kybernetes, 35(5), 632–652.
Bajgoric, N. (2006b). Information technologies for business continuity: an implementation
framework. Information Management & Computer Security, 14(5), 450–466.
Bajgoric, N. (2014). Business continuity management: A systemic framework for
implementation. Kybernetes, 43(2), 156–177.
Baskerville, R., Baiyere, A., Gregor, S., Hevner, A. R., & Rossi, M. (2018). Design Science
Research Contributions: Finding a Balance between Artifact and Theory. Journal of the
Association for Information Systems, 19(5), 358–376.
Bell, R., & Gomez, E. A. (2011). Business continuity for small business owners: Do the tools
fit their need? In 8th International Conference on Information Systems for Crisis
Response and Management: From Early-Warning Systems to Preparedness and
Training, ISCRAM 2011. Information Systems for Crisis Response and Management,
ISCRAM.
Bilili, S., & Raymond, L. (1993). Information technology: threats and opportunities for small
and medium‐sized enterprises. International Journal of Information Management, (6),
439–438.
Bostrom, R. P., & Heinen, J. S. (1977). MIS Problems and Failures: A Socio-Technical
Perspective. Part I: The Causes. MIS Quarterly, 1(3), 17–32.
Botha, J., & Von Solms, R. (2004). A cyclic approach to business continuity planning.
Information Management and Computer Security, 12(4), 328–337.
Branicki, L. J., Sullivan-Taylor, B., & Livschitz, S. R. (2018). How entrepreneurial resilience
generates resilient SMEs. International Journal of Entrepreneurial Behavior & Research,
24(7), 1244–1263.
Braun, T. L., & Martz, W. B. (2007). Business continuity preparedness and the mindfulness
state of mind. In AMCIS 2007 Proceedings (Vol. 3, pp. 2002–2010).
Burton-Jones, A., Wai, F. B., Oborn, E., & Padmanabhan, B. (2021). Advancing Research
Transparency at MIS Quarterly: A Pluralistic Approach. MIS Quarterly, 45(2), piii-xviii.
Butler, B. S., & Gray, P. H. (2006). RELIABILITY, MINDFULNESS, AND INFORMATION
SYSTEMS. MIS Quarterly, 30(2), 211–224.
Cerullo, V., & Cerullo, M. J. (2004). Business Continuity Planning: A Comprehensive
Approach. Information Systems Management, 21(3), 70–78.
Chen, H., Lee, M., & Wilson, N. (2007). Resource Constraints Related to Emerging Integration
Technologies Adoption: The Case of Small and Medium-Sized Enterprises. AMCIS 2007
Proceedings.
Cherns, A. (1976). The Principles of Sociotechnical Design. Human Relations, 29(8), 783–
792.
Cumbie, B. A. (2007). The Essential Components of Disaster Recovery Methods: A Delphi
Study Among Small Businesses. In AMCIS 2007 Proceedings (Vol. 115).
Davenport, T., & Short, J. (1990). The new industrial engineering: information technology and
business process redesign. Sloan Management Review, 31(4).
De Haes, S., Huygh, T., Joshi, A., & Van Grembergen, W. (2016). Adoption and Impact of IT
Governance and Management Practices. International Journal of IT/Business Alignment
and Governance, 7(1), 50–72.
Dernbecher, S., & Beck, R. (2017). The concept of mindfulness in information systems
research: A multi-dimensional analysis. European Journal of Information Systems, 26(2),
121–142.
Devargas, M. (1999). Survival is Not Compulsory: An Introduction to Business Continuity
Planning. Computers & Security, 18(1), 35.
Devos, J., Landeghem, H. Van, & Deschoolmeester, D. (2012). Rethinking IT governance for
SMEs. Industrial Management and Data Systems, 112(2), 206–223.
Fani, S. V., & Subriadi, A. P. (2019). Business Continuity Plan: Examining of Multi-Usable
Framework. In Procedia Computer Science (Vol. 161, pp. 275–282). Elsevier B.V.
Freestone, M., & Lee, M. (2008). Planning for and surviving a BCM audit. Journal of Business
Continuity & Emergency Planning, 2(2), 138–151.
Geelen-Baass, B. N. L. L., & Johnstone, J. M. K. K. (2008). Building resiliency: ensuring
business continuity is on the health care agenda. Australian Health Review, 32(1), 161–
173.
Gibb, F., & Buchanan, S. (2006). A framework for business continuity management.
International Journal of Information Management, 26(2), 128–141.
Gregor, S., & Hevner, A. R. (2013). POSITIONING AND PRESENTING DESIGN SCIENCE
Types of Knowledge in Design Science Research. MIS Quarterly, 37(2), 337–355.
Gregor, S., & Jones, D. (2007). The anatomy of a design theory. Journal of the Association
for Information Systems, 8(5), 312–335.
Gregory, R. W., & Muntermann, J. (2014). Heuristic theorizing: Proactively generating design
theories. Information Systems Research, 25(3), 639–653.
Haghighi, S. M., & Torabi, S. A. (2019). Business continuity-inspired fuzzy risk assessment
framework for hospital information systems. ENTERPRISE INFORMATION SYSTEMS.
Halonen, R., & Koutonen, S. (2010). Planning continuity-case manufacturing industry. In
Business Transformation through Innovation and Knowledge Management: An Academic
Perspective (Vol. 2, pp. 713–724). International Business Information Management
Association, IBIMA.
Harris, R., & Grimaila, M. R. (2008). Information Technology Contingency Planning. In SAIS
2008 Proceedings (p. 1).
Heidt, M., & Gerlach, J. P. (2018). The Influence of SME Constraints on Organizational IT
Security. ICIS 2018 Proceedings.
Hendela, A. H., Turoff, M., Hiltz, S. R., & Fjermestad, J. L. (2017). A Risk Scenario for Small
Businesses in Hurricane Sandy Type Disasters. In Proceedings of the 50th Hawaii
International Conference on System Sciences | 2017.
Herbane, B. (2010a). Small business research: Time for a crisis-based view. International
Small Business Journal, 28(1), 43–64.
Herbane, B. (2010b). The evolution of business continuity management: A historical review of
practices and drivers. Business History, 52(6), 978–1002.
Herbane, B. (2013). Exploring Crisis Management in UK Small- and Medium-Sized
Enterprises. Journal of Contingencies and Crisis Management, 21(2), 82–95.
Herbane, B. (2019). Rethinking organizational resilience and strategic renewal in SMEs.
Entrepreneurship and Regional Development, 31(5–6), 476–495.
Herbane, B., Elliott, D., & Swartz, E. (2004). Business Continuity Management: time for a
strategic role? Long Range Planning, 37(5), 435–457.
Hern, A. (2017, April 30). WannaCry, Petya, NotPetya: how ransomware hit the big time in
2017. The Guardian.
Hevner, A. R. (2007). A three cycle view of design science research. Scandinavian journal of
information systems, 19(2), 1–6.
Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information
Systems Research. MIS Quarterly, 28(1), 75–105.
Hevner, A. R., & Parsons, J. (2021). Research Transparency in Design Science Research -
Panel proposal. In DESRIST 2021.
Hiles, A. (2011). The Definitive Handbook of Business Continuity Management. Chichester,
United Kingdom: John Wiley & Sons, Ltd.
Hiles, A. (2017). Business Continuity Management: Global Best Practices (4th Edition) by
Andrew Hiles | Continuity Insights. (K. Noakes-Frye, Ed.) (4th ed.). Brookfield,
Connecticut, USA: Rothstein Associates, Incorporated.
Idrees, A. M., El Seddawy, A. I., & El Moaaz, M. (2019). A proposed mining based business
continuity information system for educational institutes. Journal of Computer Science,
15(8), 1133.1149.
Iivari, J. (2020). Editorial: A critical look at theories in design science research. Journal of the
Association for Information Systems, 21(3), 502–519.
Iivari, N., & Kuutti, K. (2017). Towards Critical Design Science Research. ICIS 2017
Proceedings.
ISO. (2012). ISO 22313:2012(en), Societal security — Business continuity management
systems — Guidance, 2012, 60.
Iyer, R. K., & Bandyopadhyay, K. (2000). Managing technology risks in the healthcare sector:
Disaster recovery and business continuity planning. Disaster Prevention and
Management: An International Journal, 9(4), 257–270.
Järveläinen, J. (2012). Information security and business continuity management in
interorganizational IT relationships. Information Management & Computer Security,
20(5), 332–349.
Järveläinen, J. (2013). IT incidents and business impacts: Validating a framework for continuity
management in information systems. INTERNATIONAL JOURNAL OF INFORMATION
MANAGEMENT, 33(3), 583–590.
Järveläinen, J. (2016). Integrated business continuity planning and information security policy
development approach. 2016 International Conference on Information Systems, ICIS
2016, 1–13.
Kato, M., & Charoenrat, T. (2018). Business continuity management of small and medium
sized enterprises: Evidence from Thailand. International Journal of Disaster Risk
Reduction, 27, 577–587.
Kendall, K. E., Kendall, J. E., & Lee, K. C. (2005). Understanding Disaster Recovery Planning
through a Theatre Metaphor: Rehearsing for a Show that Might Never Open.
Communications of the Association for Information Systems, 16(1).
Kepenach, R. J. (2007). Business continuity plan design: 8 Steps for getting started designing
a plan. In Second International Conference on Internet Monitoring and Protection, ICIMP
2007.
Kinnunen, H., & Siponen, M. (2018). Developing Organization-Specific Information Security
Policies. PACIS 2018 Proceedings.
Kuechler, B., & Vaishnavi, V. (2008). On theory development in design science research:
Anatomy of a research project. European Journal of Information Systems, 17(5), 489–
504.
Lebek, B., Uffen, J., Neumann, M., Hohler, B., & Breitner, M. H. (2014). Information security
awareness and behavior: A theory-based literature review. Management Research
Review, 37(12), 1049–1092.
Lincoln, Y. S., & Guba, E. G. (1986). But is it rigorous? Trustworthiness and authenticity in
naturalistic evaluation. New Directions for Program Evaluation, 1986(30), 73–84.
Lindström, J., Harnesk, D., Laaksonen, E., & Niemimaa, M. (2010). A Methodology for Inter-
Organizational Emergency Management Continuity Planning. International Journal of
Information Systems for Crisis Response and Management, 2(4), 1–19.
Lindström, J., Samuelsson, S., & Hägerfors, A. (2010). Business continuity planning
methodology. Disaster Prevention and Management: An International Journal, 19(2),
243–255.
Lins, S., Schneider, S., Szefer, J., Ibraheem, S., & Sunyaev, A. (2019). Designing monitoring
systems for continuous certification of cloud services: Deriving metarequirements and
design guidelines. Communications of the Association for Information Systems, 44(1),
460–510.
Macpherson, A., Herbane, B., & Jones, O. (2015). Developing dynamic capabilities through
resource accretion: expanding the entrepreneurial solution space. Entrepreneurship &
Regional Development, 27(5–6), 259–291.
March, S. T., & Smith, G. F. (1995). Design and natural science research on information
technology. Decision Support Systems, 15(4), 251–266.
Merhout, J. W., & Havelka, D. (2008). Information Technology Auditing: A Value-Added IT
Governance Partnership between IT Management and Audit. Communications of the
Association for Information Systems, 23, 463–482.
Mijnhardt, F., Baars, T., & Spruit, M. (2016). Organizational Characteristics Influencing SME
Information Security Maturity. Journal of Computer Information Systems, 56(2), 106–115.
Miles, M. B., & Huberman, M. (1994). Qualitative Data Analysis: An Expanded Sourcebook -
Matthew B. Miles, A. Michael Huberman - Google Books (2.). Thousand Oaks: SAGE.
Moody, G. D., Siponen, M., & Pahnila, S. (2018). Toward a unified model of information
security policy compliance. MIS Quarterly: Management Information Systems, 42(1),
285–311.
Mumford, E. (2006). The story of socio-technical design: Reflections on its successes, failures
and potential. Information Systems Journal, 16(4), 317–342.
Niemimaa, E., & Niemimaa, M. (2017). Information systems security policy implementation in
practice: from best practices to situated practices. European Journal of Information
Systems, 26(1), 1–20.
Niemimaa, M. (2015a). Extending “Toolbox” of Business Continuity Approaches: Towards
Practicing Continuity. In AMCIS 2015 Proceedings (pp. 1–11).
Niemimaa, M. (2015b). Interdisciplinary Review of Business Continuity from an Information
Systems Perspective: Toward an Integrative Framework. Communications of the
Association for Information Systems, 37(1), 69–102.
Niemimaa, M. (2017). Information systems continuity process: Conceptual foundations for the
study of the “social.” Computers and Security, 65, 1–13.
Niemimaa, M., & Järveläinen, J. (2013). IT service continuity: Achieving embeddedness
through planning. Proceedings - 2013 International Conference on Availability, Reliability
and Security, ARES 2013, 333–340.
Niemimaa, M., Järveläinen, J., Heikkilä, M., & Heikkilä, J. (2019). Business continuity of
business models: Evaluating the resilience of business models for contingencies.
International Journal of Information Management, 49, 208–216.
Niemimaa, M., & Niemimaa, E. (2019). Abductive innovations in information security policy
development: an ethnographic study. European Journal of Information Systems, 28(5),
566–589.
Nosworthy, J. D. (2000). A practical risk analysis approach: Managing BCM risk. Computers
and Security, 19(7), 596–614.
Peffers, K., Tuunanen, T., & Niehaves, B. (2018). Design science research genres:
introduction to the special issue on exemplars and criteria for applicable design science
research. European Journal of Information Systems, 27(2), 129–139.
Peterson, C. A. (2009). Business Continuity Management & guidelines. In Proceedings of the
2009 Information Security Curriculum Development Annual Conference, InfoSecCD’09
(pp. 114–120).
Pinta, J. (2011). Disaster recovery planning as part of business continuity management. Agris
On-line Papers in Economics and Informatics, 3(4), 55–61.
Pitt, M., & Goyal, S. (2004). Business continuity planning as a facilities management tool.
Facilities, 22(3/4), 87–99.
Pratt, M. G., Kaplan, S., & Whittington, R. (2020). Editorial Essay: The Tumult over
Transparency: Decoupling Transparency from Replication in Establishing Trustworthy
Qualitative Research*. Administrative Science Quarterly, 65(1), 1–19.
Reuter, C. (2015). Towards Efficient Security: Business Continuity Management in Small and
Medium Enterprises: Government & Law Journal Article | IGI Global. International Journal
of Information Systems for Crisis Response and Management, 7(3), 69–79.
Sakurai, M., & Kokuryo, J. (2014). Design of a Resilient Information System for Disaster
Response. In ICIS 2014 Proceedings (p. 1). Auckland.
Salovaara, A., Lyytinen, K., & Penttinen, E. (2019). High reliability in digital organizing:
Mindlessness, the frame problem, and digital operations. MIS quarterly, 43(2), 555–578.
Sambo, F., & Bankole, F. O. (2016). A normative process model for ICT business continuity
plan for disaster management in small, medium and large enterprises. International
Journal of Electrical and Computer Engineering, 6(5), 2425–2431.
Sarkar, A., Wingreen, S. C., & Cragg, P. (2017). CEO Decision Making under Crisis: An
Agency Theory Perspective. Pacific Asia Journal of the Association for Information
Systems, 9(2), 1–22.
Sawalha, I. H. S., Anchor, J. R., & Meaton, J. (2015). Continuity Culture: A Key Factor for
Building Resilience and Sound Recovery Capabilities. International Journal of Disaster
Risk Science, 6(4), 428–437.
Schultze, U. (2000). A Confessional Account of an Ethnography about Knowledge Work. MIS
Quarterly, 24(1), 3–41.
Schultze, U., Heuvel, G. van den, & Niemimaa, M. (2020). Enacting Accountability in IS
Research after the Sociomaterial Turn(ing). Journal of the Association for Information
Systems, 21(4), 10.
Shropshire, J., Kadlec, C., & Shropshire, J. (2009). Establishing the IT Disaster Recovery
Planning Construct. In AMCIS 2009 Proceedings (Vol. 20, p. 37).
Siponen, M., Soliman, W., & Holtkamp, P. (2021). Research Perspectives: Reconsidering the
Role of Research Method Guidelines for Interpretive, Mixed Methods, and Design
Science Research. Journal of the Association for Information Systems, 22(4), 1176–
1196.
Siponen, M., & Willison, R. (2009). Information security management standards: Problems
and solutions. Information & Management, 46(5), 267–270.
Smith, D. (2003). Business continuity and crisis management. Management Quarterly, 27–33.
Spears, J. L., & Barki, H. (2010). User Participation in Information Systems. MIS Quarterly,
34, 503–522.
Star, S. L., & Ruhleder, K. (1996). Steps Toward an Ecology of Infrastructure: Design and
Access for Large Information Spaces. Information Systems Research, 7(1), 111–134.
Sullivan-Taylor, B., & Branicki, L. (2011). Creating resilient SMEs: Why one size might not fit
all. International Journal of Production Research, 49(18), 5565–5579.
Sutcliffe, K. M., Vogus, T. J., Dane, E., & Jones, J. H. (2016). Mindfulness in Organizations: A
Cross-Level Review. Annual Review of Organizational Psychology and Organizational
Behavior, 3, 55–81.
Tammineedi, R. L. (2010). Business Continuity Management: A Standards-Based Approach.
Information Security Journal: A Global Perspective, 19(1), 36–50.
Tapanainen, T., & Kamioka, T. (2013). Chief Information Officer (CIO) Leadership in Crisis
Situations: Subordinate Stories from the Japan Earthquake Crisis. In PACIS 2013
Proceedings (pp. 6–18).
Tjoa, S., Jakoubi, S., & Quirchmayr, G. (2008). Enhancing Business Impact Analysis and Risk
Assessment Applying a Risk-Aware Business Process Modeling and Simulation
Methodology. In 2008 Third International Conference on Availability, Reliability and
Security (pp. 179–186). IEEE.
Torabi, S. A., Rezaei Soufi, H., & Sahebjamnia, N. (2014). A new framework for business
impact analysis in business continuity management (with a case study). Safety Science,
68, 309–323.
Tracey, S., O’Sullivan, T. L., Lane, D. E., Guy, E., & Courtemanche, J. (2017). Promoting
Resilience Using an Asset-Based Approach to Business Continuity Planning. SAGE
Open, 7(2), 215824401770671.
Turetken, O. (2008). Is your back-up IT infrastructure in a safe location?:A multi-criteria
approach to location analysis for business continuity facilities. Information Systems
Frontiers, 10(3), 375–383.
Ueno, W. H., De Barros, R. M., & Brancher, J. D. (2018). Gaia maturity model to deploy IT
services continuity. In AMCIS 2018 Proceedings. Association for Information Systems.
Valorinta, M. (2009). Information technology and mindfulness in organizations. Industrial and
Corporate Change, 18(5), 963–997.
Van Maanen, J. (2011). Ethnography as Work: Some Rules of Engagement. Journal of
Management Studies, 48(1), 218–234.
Vargo, J., & Seville, E. (2011). Crisis strategic planning for SMEs: finding the silver lining.
International Journal of Production Research, 49(18), 5619–5635.
Vogus, T. J., & Sutcliffe, K. M. (2007). The Safety Organizing Scale: Development and
Validation of a Behavioral Measure of Safety Culture in Hospital Nursing Units on JSTOR.
Medical Care, 45(1), 46–54.
Vogus, T. J., & Sutcliffe, K. M. (2012). Organizational Mindfulness and Mindful Organizing: A
Reconciliation and Path Forward. Article in Academy of Management Learning and
Education, 11(4), 722–735.
Vom Brocke, J., Gau, M., & Mädche, A. (2021). Journaling the Design Science Research
Process. Transparency About the Making of Design Knowledge, 131–136.
Wan, S., Stewart, W., & Wan, S. (2009). Service impact analysis using business continuity
planning processes. Campus-Wide Information Systems, 26(1), 20–42.
Wang, Y. S., Wu, S. C., Lin, H. H., & Wang, Y. Y. (2010). The relationship of service failure
severity, service recovery justice and perceived switching costs with customer loyalty in
the context of e-tailing. International Journal of Information Management, 31(4), 350–
359.
Weick, K. E., Sutcliffe, K. M., & Obstfeld, D. (1999). Organizing for high reliability: Processes
of collective mindfulness. In R. S. Sutton & B. M. Staw (Eds.), Research in Organizational
Behavior (Vol. 3, pp. 81–123). Greenwich, CT: JAI Press.
Winkler, U., Fritzsche, M., Gilani, W., & Marshall, A. (2010). A model-driven framework for
process-centric Business Continuity Management. Proceedings - 7th International
Conference on the Quality of Information and Communications Technology, QUATIC
2010, (1), 248–252.
Appendix A: An Overview of Prior Business Continuity
Approaches
Business continuity as a subject has close ties to practice and practitioners as well as being
highly multidisciplinary (Niemimaa, 2015). In order to find essential literature for our purposes,
we conducted a systematic literature review. We searched the Web of Science (WoS),
Scopus, and AIS eLibrary databases with search terms “business continuity management” or
“business continuity plan*” and “information system*”. With no time ranges, we found 41
articles from WoS, 104 articles from Scopus, and 234 from AIS eLibrary, which amounted to
257 in total after checking for duplicates. In order to have a more manageable stack of papers,
we decided to include scientific journal articles and books as well as conference papers from
ICIS, ECIS, PACIS, and AMCIS (but exclude others, unless they contained some of the search
terms more than three times in the main text and their reference list was scientific). After this
search term frequency checking, we found 95 papers, which were screened more carefully to
find papers with requirements for models of business continuity management or planning,
which left us with 36 papers. Papers that were discarded focused, for example, on technical
details (such as sensor networks), information security, or described disaster recovery cases
(e.g., after hurricane Katrina).
After this we checked the scientific papers from Niemimaa’s (2015b) literature review focusing
on models that develop IS continuity for the same requirements. From this we found nine more
papers, which stated some requirements for models of business continuity management or
planning. In Table A.1, we present the papers included in the literature review and the
requirements they posed for BC management and planning models.
Table A.1. Literature posing requirements for BC management or planning models (in the order of most fulfilled
MRs).
Paper
Focus
Research approach
MR1 ‘Facilitate embeddedness’
MR2 ‘Pay attention to context’
MR3 ‘Maintain accuracy’
MR4 ‘Develop gradually’
MR5 ‘Minimize documentation’
MR6 ‘Enable self-assessment
and improvement’
MR7 ‘Develop jointly the social
and the technical’
MR8 ‘Facilitate collective and
participatory development’
MR9 ‘Revere substance
expertise’
MR10 ‘Attend proactively’
Other criteria
(Järveläinen, 2016)
Integration of
BCP and ISP
Conceptual
X
F
x
x
x
x
x
Involving
experts and
end-users from
business units
(Lindström,
Samuelsson et al.,
2010)
BC planning
methodology
Case
x
P
x
x
x
x
x
Organizational
and
departmental
approaches,
targeted for
senior
management
Paper
Focus
Research approach
MR1 ‘Facilitate embeddedness’
MR2 ‘Pay attention to context’
MR3 ‘Maintain accuracy’
MR4 ‘Develop gradually’
MR5 ‘Minimize documentation’
MR6 ‘Enable self-assessment
and improvement’
MR7 ‘Develop jointly the social
and the technical’
MR8 ‘Facilitate collective and
participatory development’
MR9 ‘Revere substance
expertise’
MR10 ‘Attend proactively’
Other criteria
(Nosworthy, 2000)
Practical BCM
approach
Conceptual
x
P
x
x
x
x
x
Consistent,
manageable,
cost-effective,
organization-
wide
(Gibb & Buchanan,
2006)
Step-by-step
approach for BC
Conceptual
F
x
x
x
x
x
Enterprise-wide
activity,
credible,
relevant, cost-
effective,
specific,
measurable,
attainable,
relevant, time-
based
(Iyer &
Bandyopadhyay,
2000)
DR & BCP for
healthcare sector
Conceptual
x
F
x
x
x
x
Structured for
the survival and
development of
an organization
as a whole
(Arduini &
Morabito, 2010)
BC in banking
industry
Conceptual
x
P
x
x
x
x
Firm-wide
scope, aiming
for crisis
prevention/avoi
dance
(Baham et al.,
2017)
DRP in
enterprise
architecture
Case
x
P
x
x
x
x
Efficiency of
recovery,
targeted for
large
organizations
(Botha & Von
Solms, 2004)
BC planning
Conceptual
x
P
x
x
x
x
Scalable for all
organizations
(Butler & Gray,
2006)
Achieving
reliability in IS
with mindfulness
Conceptual
x
P
x
x
x
x
Not only
routine-based,
but individual
and collective
mindfulness are
needed for
reliable IS.
(Kepenach, 2007)
BCP design
Conceptual
P
x
x
x
x
x
Holistic
(Tammineedi,
2010)
Standards-based
BCM
Conceptual
x
P
x
x
x
x
Holistic (all
business units)
and integrated
(Halonen &
Koutonen, 2010)
Implementation
of BCP for large
company
Case
F
x
x
x
x
Applicable for
manufacturing
firms too
COBIT 2019
(Manage
Continuity)
(ISACA, 2018)
Controlling IT
service
management
-
x
P
x
x
x
Holistic,
focused on all
IT service
management
with extensive
instructions
Paper
Focus
Research approach
MR1 ‘Facilitate embeddedness’
MR2 ‘Pay attention to context’
MR3 ‘Maintain accuracy’
MR4 ‘Develop gradually’
MR5 ‘Minimize documentation’
MR6 ‘Enable self-assessment
and improvement’
MR7 ‘Develop jointly the social
and the technical’
MR8 ‘Facilitate collective and
participatory development’
MR9 ‘Revere substance
expertise’
MR10 ‘Attend proactively’
Other criteria
(Dynes, Pixley, &
Madory, 2009)
Medium-sized
hospital
Case
P
x
x
x
x
Clear and
simple plans
that could be
used effectively,
any time by
different staff.
Enterprise-level
plan from
integrated unit
plans.
(Geelen-Baass &
Johnstone, 2008)
Generic BCM
framework
Case
x
P
x
x
x
Simple process,
holistic, and
organization-
wide
(Niemimaa, 2015a)
Practicing
continuity
Conceptual
x
P
x
x
x
Plans,
technological
solutions, or
social ingenuity
is not enough,
BC practices
essential
(Peterson, 2009)
BCM guidelines
Conceptual
P
x
x
x
x
Can be costly
endeavor to
undertake,
requires
attention of
almost
everyone in an
organization.
(Smith, 2003)
BCM model
Conceptual
x
P
x
x
x
All-embracing in
nature
(business-wide,
not IT focus),
documentation
should not be
‘too heavy to lift’
(Motevali Haghighi
& Torabi, 2019)
Risk assessment
method for a
hospital
Case
F
x
x
x
Practical and
quantitatively
measurable
(Bell & Gomez,
2011)
BC for small
businesses
Conceptual
P
x
x
x
Provide sense-
making
capabilities and
training for
small
companies
(Cerullo & Cerullo,
2004)
BCP for IS
management
Conceptual
P
x
x
x
Comprehensive
(Fani & Subriadi,
2019)
Implementation
of BCP
Multiple cases
P
x
x
x
Applicable for
all companies
regardless of
size, activity, or
sector
FitSM (ITEMO,
2019)
Lightweight
standard for IT
service
management
-
P
x
x
x
Holistic,
focused on all
IT service
management
with extensive
instructions
Paper
Focus
Research approach
MR1 ‘Facilitate embeddedness’
MR2 ‘Pay attention to context’
MR3 ‘Maintain accuracy’
MR4 ‘Develop gradually’
MR5 ‘Minimize documentation’
MR6 ‘Enable self-assessment
and improvement’
MR7 ‘Develop jointly the social
and the technical’
MR8 ‘Facilitate collective and
participatory development’
MR9 ‘Revere substance
expertise’
MR10 ‘Attend proactively’
Other criteria
(Harris & Grimaila,
2008)
IT contingency
planning
Conceptual
P
x
x
x
Comprehensive
(Hecht, 2002)
BCM
Conceptual
x
P
x
x
Costs and risks
should be
balanced
(Hendela et al.,
2017)
Risk scenarios
for small
businesses
Multi-method
P
x
x
x
Structured and
simplified,
scenario-based
(Idrees et al.,
2019)
BC IS for
educational
institutes
Surveys
P
x
x
x
(ITIL 4 Foundation,
Module 4 & 5
Study Guide,
2019)
Governance
framework
-
x
P
x
x
Comprehensive
, focused on all
IT service
management
with extensive
instructions
(Labus,
Despotović-Zrakić,
& Bogdanović,
2017)
E-business
continuity
management
Multiple cases
P
x
x
x
Simple
(Morgan et al.,
2015)
BCM in blood
services
Multiple cases
P
x
x
x
(Morisse & Prigge,
2017)
Resilience in
Industry 4.0
Case
x
P
x
x
(Pinta, 2011)
DRPs in BCM
Conceptual
x
P
x
x
For smaller
organizations,
one plan of
continuity may
be quite
sufficient.
(Shropshire et al.,
2009)
DRP construct
creation, IT
service
Literature review
x
x
x
Offering
guidance for
practitioners
(Ueno et al., 2018)
Maturity model
for IT service
continuity
Survey
F
x
x
(Braun & Martz,
2007)
Mindfulness and
BC
Conceptual
P
x
x
Company-wide
effort
(Cumbie, 2007)
DRP in small
businesses
Delphi study
P
x
x
Cost-effective
for small
businesses
(Paton, 1999)
Staff role in
business
continuity
Conceptual
P
x
x
Commitment
from staff
through training
(Sarkar et al.,
2017)
SME resilience
from CEO
perspective
Q methodology
P
x
x
Some SMEs
prefer routines
and plans
whereas others
may focus on
mindfulness-
Paper
Focus
Research approach
MR1 ‘Facilitate embeddedness’
MR2 ‘Pay attention to context’
MR3 ‘Maintain accuracy’
MR4 ‘Develop gradually’
MR5 ‘Minimize documentation’
MR6 ‘Enable self-assessment
and improvement’
MR7 ‘Develop jointly the social
and the technical’
MR8 ‘Facilitate collective and
participatory development’
MR9 ‘Revere substance
expertise’
MR10 ‘Attend proactively’
Other criteria
based resiliency
strategies.
(Merhout &
Havelka, 2008)
IT auditing
Conceptual + short
case
x
x
For entire
organization
(Sakurai &
Kokuryo, 2014)
Resilient IS after
a disaster
Case
F
x
Frugality,
creative
responses, and
swift recovery
after major
disaster
(Bajgoric, 2014)
BCM framework,
system level
Conceptual
P
x
Systemic
implementation,
technical focus
(Morisse & Prigge,
2014)
BC in networked
organizations
Literature review
P
x
In networked
organizations,
formal BC
manager and
sharing
information in
disruptions is
needed
(Sambo &
Bankole, 2016)
Reasons behind
disruptions with
BCP in place
Case
P
x
Comprehensive
and rigorous
(Wan et al., 2009)
Service impact
analysis
Case
P
Business-wide,
integrated with
DRP (IT service
continuity
management),
dynamic
Total
17
42
2
8
9
2
6
31
17
4
3
3
P = partially met, considers the company context (n= 35), F = fully met, considers both context as well as existing
BC measures (n=7).
Appendix B: The Thrifty BC Management Approach
This appendix presents the designed Thrifty BC Management Approach to assist practitioners
in self-assessing and developing their BC Management (MR6). It consists of two parts. First,
we present the approach itself including material already presented as part of the research
article (e.g., an overview of the process and modules) and supplementary material (e.g.,
guiding questions for all modules) to offer practitioners a handguide-like description of the
artifact in a single place. Second, we describe a workshop approach that practitioners can
adopt for implementing the Thrifty BC Management Approach.
Appendix B. Part 1: Process Model, Trigger Points, and Guiding Questions
The Thrifty BC Management Approach comprises three phases and, in total, 16 modules (see
Figure B.1). The first phase is the Map-it phase. Its modules comprise guiding questions for
assessing SMEs’ business context including their most critical business process (see Table
B.1). The second phase, Design-it, involves modules focusing on defining BC measures.
Table B.3 presents respective guiding questions assisting SMEs with designing BC measures.
In the third and last phase, Continue-it, SMEs decide on how they operate and monitor the
designed BC measures (Table B.4 presents the respective guiding questions) and when as
well as how they continue with subsequent iterations of the Thrifty BC Management Approach.
For this, the approach uses a set of three trigger points: gradual development, re-evaluation,
and major update (see Table B.5). We suggest that companies define which events are
relevant trigger points for maintaining and updating their BC management using this
classification of trigger points. Illustrating the implementation process, and particularly, how
these trigger points entail an iterative BC planning process, we provide Figure B.2.
Figure B.1. Process and modules of the Thrifty BC Management Approach
Table B.1. Goals and guiding questions for Map-it phase. (Note: There might be overlapping questions across the
phases, which can be ignored during the workshop if already discussed.)
Module—Goals of the Module
Guiding Questions
Business Continuity Environment
Mapping
• Listing all critical external and
internal factors such as suppliers,
(key) customers, and their
requirements, legislation and
company strategy
• Which suppliers support your critical business
processes? Which role do these suppliers take in your
business process?
• Which key customers depend on your critical business
processes? What requirements do they have of your BC?
• Do you have any legal requirements of your BC?
• How is your company strategy related to your BC (value
preservation)? How are these factors influencing your
business and/or BC? How critical are these factors (esp.
suppliers/customers) for your business?
Critical Business Process Mapping
• Identify critical business processes
and the different functions
performed in these processes
• Choose the most critical process
for further examination
• Identify interfaces to other
processes, stakeholders, and
responsibilities (process owner)
• What are the most critical business processes, without
which your business would not survive? A disruption of
which business process would immediately (in two hours,
one day, etc.) terminate your business?
• What are the key functions in this critical business
process?
• Which processes are customer-facing processes (if
critical to the company)?
• Which other processes might be affected if this critical
business processes (function) is disrupted?
• Who is responsible for this critical process (process
owner)?
• Is this critical business process supported or used by any
external party (supplier/customer)?
• On which of your premises is this process performed?
Critical Data & Application
Mapping
• Which applications is this critical business process relying
on? To which other applications (information systems)
Design-it
Process Recovery
Management I nfrastructure Resilience
Contingency Planning Critical Premi ses & Facilities
Backup Mana gement Insurance Prote ction
Essential Inform ation
Security Fun ction
Map-it
Environmental/E xternal
Requirements M apping Critical Infrastru cture
Mapping
Critical Data & Application
Mapping
Critical Busin ess Process
Mapping Risk Analysis
Co ntinue -it
BC Manage ment BC Supplier Man agement
Crisis Mana gement External & Inte rnal
Communicati on Management
Co nti nue an d m onito r
de signe d B C m ea sure s
• Identify all the applications and
data on which your critical
business process relies on
• Map these applications, their
connection to other applications,
external stakeholders, information
assets, and responsibilities
are these applications connected? Who is responsible for
these applications (information systems)?
• Which data are those applications relying on? Which
information is crucial to conduct the critical business
processes?
• Are there customers or suppliers who have access to this
system to use or maintain it? Are some of these
information systems external services?
Critical Infrastructure Mapping
• Identify the infrastructure on which
your applications and critical
business process relies on
• Map your infrastructure
components, locations, external
stakeholders, and responsibilities
etc.
• On which IT infrastructure (e.g., servers, networks,
firewall, computers, and other devices, etc.) are the
critical process and supporting applications) relying?
Which IT infrastructure component failure would disrupt
your critical business process?
• In which facilities is your IT infrastructure located?
• Where is this infrastructure maintained in your company
or outside your company (supplier)? Who is responsible
for these infrastructure nodes? Are there customers
whose processes rely on your infrastructure?
Risk Analysis
• Risk identification
• Risk assessment
• Risk treatment
• Risk mapping
• (Risk matrix; risk event per
process, sorted by relevance (P*I),
depicted in a matrix; see Table B.2
for an exemplary risk matrix)
• Which events (hazards; use a risk catalogue as
facilitation) could cause a disruption of your critical
business processes?
• What impact (e.g., financial, reputational damage, etc.)
would it have if these events occurred (low = 1, moderate
= 2, high = 3)? How likely is it that this risk occurs (risk
probability: unlikely = 1, likely = 2, very likely = 3)?
• What are possible risk strategies to handle these risks?
(Avoid, mitigate the likelihood of occurrence or transfer)
Consider the cost/benefit ratio for the different strategies;
How much are you willing to pay for the risk treatment?
Table B.2. An exemplary risk matrix
Risk name
Impact
Probability
Risk Severity
IT service provider does not handle the incident quickly
(less than a week)
1
1
1
Production system is interrupted (e.g., malware, flood,
fire)
3
2
6
Confidential data leaks from the production system
1
1
1
Power outage damages the production system
1
3
3
The critical server breaks
1
2
2
Backups cannot be used for recovery
1
1
1
Malware damages the critical systems
1
1
1
Major fire
3
1
3
Confidential information is leaked because of breaking
and entering
1
1
1
Personnel risk
3
1
3
Impact: 1: minor, 2: moderate, 3: significant. Probability: 1: small, 2: medium, 3: large.
Table B.3. Goals and guiding questions for Design-it phase. (Note: There might be overlapping questions across
the phases, which can be ignored during the workshop if already discussed.)
Module—Goals of the module
Guiding questions
Process Recovery Management
• Define time goals for process
recoveries and discuss required
developments for current recovery
plan
• Outline plans for recovering the
critical business processes
• Assign responsibilities and contact
persons
• Testing of the process recovery
(against time goals)
• What kind of losses would you suffer if your critical
business process was disrupted for X hours?
• What kind of actions and/or processes are required to
recover a system and/or process after a disruption (e.g.,
alternative process, skipping a process phase, manual
process)?
• Who should be informed about the disruption? What
information should be communicated (for how long will it
be disrupted; time of updates; alternative processes)?
• If no interruption can be tolerated, do you need a hot
site, clustering/mirroring, other redundancy, or
alternative processes, or can you manage with backups
and their recovery? How much are you willing to pay for
this recovery time objective?
• Who should be responsible for the recovery
action/process? How could you train employees or
exercise for a disruption?
Contingency planning/Alternative
processes
• Define redundant processes and
minimum required process
functionality
• Define when to switch to
alternative processes
• Choose a person to prepare the
alternative process
• What are the essential operations that need to be
performed to continue your business?
• If you need alternative processes for this critical process,
how could it be managed? Is an alternative system for a
system essential for the critical process? Do you need
alternative key persons?
• What is the minimum process/system functionality?
When should you start using the alternative
process/system? Who should be responsible for
preparing this alternative? (Testing and communicating
of the alternative processes)
Backup management
• Definition of a backup policy
containing information regarding
backup management (backup
restoration process, retention time
for backups)
• Physical protection of backup
(location and process safety level)
• Testing of the backup restoration
• Is there some data that have to be up-to-date all the
time? How often should data be backed-up (frequency of
backups)?
• Where and when should it be backed-up? How (and
where) are backups restored? At which time of the day
are backups created?
• How often should the recovery of backups be tested?
For how long should backups be stored (backup
retention time)? Transporting backups to physical
storage location: how safe is the transport process?
• Who should be responsible for backup processes?
Essential Information Security
Functions
• Malware Protection/Endpoint
protection/Patching
• System access control (end user
rights management, login control)
and monitoring log files (i.e., admin
login and critical application log
controls)
• Network security (firewall,
encryption, segregation,
monitoring of critical devices, etc.)
• Information Security Policy
(obligatory in work contracts but
also during recruitment)
• Considering the identified information security-related
risks toward your critical business processes:
• Are your critical information systems protected against
malware? Do you have a system access control in
place? Do you regularly monitor the log files for critical
systems? Is your network protected against, for
example, eavesdropping or unauthorized access?
• Do you have a patching routine for your information
systems, applications, and operating systems (e.g.,
servers)? From a change management perspective, do
you test software updates or patches before releasing
them?
• Do you have a security or data protection statement
included in your HR processes (e.g., recruiting)?
• Who should be responsible for making required changes
to essential information security functions?
Infrastructure Resilience
• Eliminate single points of failure
• Designated secured and protected
facilities for critical infrastructure
• How can you access your infrastructure (network)? Is
your network built as a circle or a star?
• Can you identify any single points of failure in your
infrastructure (servers, networks)? Which component's
and geographically considered
placement of recovery assets
• Action in case of a power outage
(e.g., backup power)
• Testing of the resiliency measures
failure would interrupt a vast number of dependent
components? How could you avoid/treat such single-
points-of-failure?
• Have you prepared for power outages? If not, how
should you?
• How often do you test that these preparations actually
work? Are there at least three persons who can do the
recovery procedures?
• Who should be responsible to make required changes to
infrastructure?
Critical premises and facilities
• Development of physical safety
• Note special protection of IT
infrastructure rooms in general (no
sprinklers, no flammables)
• Redundant storage of business-
critical, paper-based documents
• Ability to support virtual, remote, or
distributed work completion
• Protection of premises against fire
and flood hazards
• Maps and plans of all premises
(i.e., for emergency evacuation)
• Where (in which facilities) is your IT infrastructure (e.g.,
servers) located? Are these locations specifically
protected (e.g., against fire, flooding, etc.)? Are there
any benefits or threats caused by the geographical
location of your IT infrastructure?
• Where are your critical paper-based documents stored?
Are these locations specifically protected against fire or
water damage or theft? Do you keep redundant copies
of critical documents in two distinct places?
• Do you have the possibility to perform work tasks
remotely/virtually?
• In general, what kind of safety measures do you have for
your premises regarding: fire, flooding, evacuation, or
other disasters? Do you have adequate protection
against fire and flooding?
• Are you prepared to evacuate if necessary (i.e., are
emergency exits highlighted and maps accurate)?
Insurance Protection
• Check existing insurance policies,
contract new insurances
• Insurances should cover:
expenses regarding premises,
expenses made for handling the
disruption. (Considerable:
protecting against non-delivery of
services/goods due to a business
disruption; Sensible: against the
loss of key staff.)
• Considering the identified risks: Are there risks that
could be transferred by insuring against financial
damage caused by these risks?
• Do you have insurance for financial damage due to fire,
water, etc.?
• Do you have an insurance against the loss of key staff?
• Do you have an insurance that covers financial damage
caused by a business disruption?
• Do you have an insurance against non-delivery of
services/goods due to a business disruption?
Table B.4. Goals and guiding questions for Continue-it phase. (Note: There might be overlapping questions across
the phases, which can be ignored during the workshop if already discussed.)
Module—Goals of the module
Guiding questions
Crisis Management
(Roles for a crisis team:
process/application owner,
system administrator, head of
crisis team)
• Create a list of contact details
and responsibilities (also 2
redundant responsibilities)
• Include information on
responsible persons for system,
application, process,
communication etc.
• Training of the crisis team
• When an interruption happens with the most critical
process, who should be responsible? Does your
organization need a preplanned crisis team?
• What actions should be taken and when? Who should be
responsible for those actions? If somebody in the defined
crisis team is not available (on business trip, holiday, etc.)
who could instead cover the responsibilities?
• Can some of the responsibilities be outsourced or is there
external expertise that might be required?
• How should the crisis team communicate in the
team/company? When should the crisis team start
working? Should there be some training for the crisis
team?
• External ad hoc contacts adding
internally missing expertise
External and Internal
Communication Management
• Define an internal
communication plan when an
event occurs during or out of
office hours
• Define an external
communication policy containing
guidelines on how to handle the
customers, media, and/or
officials
• Consider special requirements
towards communication in case
of major incidents
• Update contact lists
• How should interruptions be communicated in the
company? When the network is down?
• After office hours, is it necessary to contact (some)
employees?
• What information should be communicated? (Which
system is down? When will it be up again? Schedule for
further updates? Will an alternative process be
performed?)
• In which cases should communication also be external
(what are the triggers)? When should customers be
informed, how, of what message, and by whom? When
should officials be informed, how, of what message, and
by whom?
• Where can contact details be found and are they updated
(how could the contact details be always up-to-date)?
BC Management
• Defining suitable metrics
monitoring the correct functioning
of the BC modules (e.g.,
backups, system health)
• Testing the effectiveness of the
designed BC modules
• Identifying required trainings
• Identifying triggers for re-
assessment and redesign of BC
modules (e.g., changes to the
business setup)
• Identifying changes to external
threats
• What metrics could monitor the correct function of your
designed BC? Considering the designed BC actions
modules:
• How could you test whether your crisis team is prepared
to handle a business disruption? How could you monitor
whether backups are performed correctly? How could you
train your employees against security risks? What tools
could you use to monitor your system health? (Are
patches done? Sufficient disk space? Service availability?)
• How can you ensure that BC is considered when a new
process/service/product is developed and introduced?
• What events could change your current business
processes and/or underlying IT systems and
infrastructure? What events (e.g., key staff leaves the
company, new hardware, system, etc.) could affect the
configuration of the designed BC modules?
BC Supplier Management
• Define supplier requirements for
BC to ensure their preparedness
for business disruptions
• Identify changes to BC
requirements that should be
communicated to external parties
• Based on the assessment, which changes to BC should
you discuss with your suppliers or customers?
• Which events should trigger a reassessment of whether
your suppliers fulfil your required BC?
• How do you evaluate your suppliers' BC? How do you
monitor changes to required standards and regulations?
How frequently should you evaluate your suppliers' BC?
• What requirements for BC do your customers demand you
fulfil? Are there any audits you need to fulfil? What legal
regulations are you required to fulfil?
Table B.5. Description, use, and purpose of the trigger points initiating consecutive iterations of the Thrifty BC
Management Approach.
Trigger Point
When
What
Purpose
Gradual
Development
When a SME has more than
one critical business process,
each additional critical business
process presents a trigger for
gradual development
Initiation of consecutive
cycles of the Map-it,
Design-it, and
Continue-it phase for
the additional critical
business process
Gradual
development, i.e.,
process by process,
of the BC
management for
SMEs
Re-evaluate
When changes in a SME’s
operation or business
environment occur that require
partial updating of the existing
Reiterate the Design-it
and Continue-it phase
for the affected
processes and
Maintaining the BC
action plan, i.e., the
designed BC
measures.
BC action plan (e.g., key
personnel changes, new ISs,
changes in key suppliers)
respective BC
measures
Major Update
When significant changes
require a new mapping of
SMEs’ crucial business
processes (e.g., merger and
acquisitions, new product,
switching from proprietary
software to cloud computing)
Conduct the entire
cycle (Map-it, Design-it,
and Continue-it) for the
affected processes
Maintaining the BC
action plan, i.e., the
designed BC
measures
Figure B.2. The Thrifty BC Management Approach implementation sequence with gradual development, re-
evaluation, and major update trigger points.
Appendix B. Part 2. Guidelines for Implementing the Thrifty BC Management
Approach within a Workshop Setting
The Thrifty BC Management Approach is designed to facilitate discussion on business
continuity (BC) management in SMEs. BC has been defined as a “capability of the
organization to continue delivery of products or services at acceptable predefined levels
following disruptive incident” (ISO, 2012). BC management focuses on the entire organization,
not only the IT function (Merhout & Havelka, 2008; Tammineedi, 2010) and thus, top
management commitment is essential for successful BC (Lindström, Samuelsson, et al., 2010;
Peterson, 2009). For implementing the Thrifty BC Management Approach, that is, for creating
the BC action plan, we suggest a workshop approach. A workshop approach reflects the
Continue-it
Re-evalu ate Triggers: In itiate iteration of Design -
it and Continue-i t for affected processes
Major Update Trigge rs: Initiate n ew mappin g of
busine ss processe s.
Gradua l Developm ent Triggers: In itiate desig n of
BC me asures for ad ditional b usiness pro cesses
notion of people participating and discussing the BC management plan using the guiding
questions presented in the previous part (part 1) of Appendix B.
Our evaluative field study suggests that two workshop sessions of 1.5 to 2.5 hours are
sufficient to complete one cycle of all three phases. The first session focuses solely on the
Map-it phase, while the second session integrates the Design-it and Continue-it phases.
SMEs’ top-management and employees with the required expertise are recommended to
participate in these workshops. The latter should be responsible and knowledgeable in the
organization’s critical business processes and IT operations. Business processes are a set of
logically-related tasks performed to achieve a defined business outcome” (Davenport & Short,
1990) and in some companies even a short interruption in a critical business process will have
significant impact on operations. Inviting employees with described expertise is crucial in
avoiding the risk of lacking sufficient knowledge on business processes’ principles or IT
infrastructure details (Weick et al., 1999). Thus, they are required to determine the existing
level of BC preparedness. However, the number of participants should be limited to ensure
thriftiness and to enable detailed as well as engaged discussions leading to a concise action
plan for BC management.
The workshop’s goal is to develop the BC preparedness of a company by identifying risks for
critical business processes and the data, IT applications, or IT infrastructure supporting the
process following the Thrifty BC Management Approach. When the potential risks have been
identified and assessed, workshop participants will decide which risks should be managed
and identify possible risk management solutions and a person responsible for continuing the
risk management planning. The outcome is an action plan describing what risk management
solutions the company has chosen and who will be responsible for planning and implementing
the solutions as well as chosen trigger points when a reassessment of risks should be done.
We have noticed that an initial structure for the action plan is easy to create after the first
workshop to list identified assets and risks, which can be used later as the starting point for
the second workshop session focusing on Design-it and Continue-it.
Once the three phases are completed, SMEs should define events that present trigger points
for gradually developing or maintaining their BC action plan. The approach is thus designed
to be iterative and gradual.
Appendix C: The Anatomy of the Design Theory for BC
Management Approaches for SMEs
Table C.1 presents the anatomy of the presented design theory. The design theory provides
design knowledge for BC management for SMEs. Outlining the theory developed in this study,
Table C.1 draws on the eight components, which Gregor and Jones (2007) suggest, from a
design theory.
Table C.1. The anatomy of the presented design theory for BC management for SMEs
Components of a Design Theory
Design Theory for Thrifty BC Management for SMEs
Purpose and scope
(“What the system is for”)
BC Management for Small and Medium-Sized Enterprises. The
design theory provides a set of ten MRs defining purpose and
scope for BC Management approaches for SMEs.
Constructs
(“Representations of the entities of
interest in the theory”)
BC Management, Small and Medium-Sized Enterprises, Map-it
phase, Design-it phase, Continue-it phase, BC Management
Modules
Principle of form and function
(“The abstract ‘blueprint’ or
architecture that describes” the
artifact)
The BC Approach takes a cyclic, continuous as well as gradual
approach to designing, implementing, and maintaining business
continuity management in SMEs. It comprises multiple modules,
which form a modular structure.
Artifact mutability
(“The changes in state of the
artifact anticipated in the theory,
[…].”)
The approach builds on a modular structure allowing for artifact
mutability. The modules are not mandatory but dependent on
SMEs’ context (Map-it phase). Thus, the approach’s modular
structure allows for artifact mutability; the modules can easily be
adjusted, removed, replaced, or complemented (i.e., new
modules added) and thus, the approach anticipates possible
changes to BC Management knowledge and practice as well as
delivers SMEs’ BC Management needs.
Testable propositions
(“Truth statements about the
design theory.”)
The BC approach facilitates SMEs to design their BC
management thriftily compared to approaches designed for
large corporations.
Justificatory knowledge
The justificatory knowledge comprises prior literature on BC
Management, Socio-technical theory, and Mindfulness.
(“The underlying knowledge or
theory […] that gives a basis and
explanation for the design.”)
The socio-technical theory and mindfulness-informed design
assumptions that contributed to the formulation of the ten MRs.
In addition, MRs stem from existing BC approaches outlined in
prior BC Management literature.
Principles of implementation
(“A description of processes for
implementing the theory (either
product or method) in specific
contexts.”)
The Thrifty BC Approach model (Map-it, Design-it, and
Continue-it), the guiding questions per module, and workshop
template (Appendix B) facilitate implementation.
Expository instantiation
(“A physical implementation of the
artifact that can assist in
representing the theory […].”)
The field evaluation provides examples of the Thrifty BC
Approach’s instantiation.
Appendix D: Evaluating this Study against the Four Practices for
Confessionally Reporting Design Science Research
In this appendix, we evaluate how our own study meets the adapted practices for
confessionally reporting DSR against a set of criteria (see Table D.1). We adapted these
criteria from the conventions for confessional ethnography (cf. Schultze, 2000; Van Maanen,
2011). Evaluating our own study, we illustrate the feasibility and usefulness of the four
practices for rendering the process in DSR transparent. However, our use of the practices and
their criteria serves only to illustrate one possible way of their application. We expect the
criteria to be relevant for (1) editors and reviewers when they need to assess confessionally
reported DSR research; (2) for researchers required to meet the expectations for research
transparency when conducting and reporting their study (Burton-Jones et al., 2021; Hevner &
Parsons, 2021; Pratt et al., 2020); and (3) for students who want to learn about DSR
processes.
Table D.1: Evaluation of this study against the four conventions for confessionally reporting DSR
Practice for
Confessionally
Reporting DSR
Practice’s Criteria
Implementation in this Study
Self-revealing
designer(s)
“Personalized
reporting of the
design study
including details
on designers,
• Using personal pronouns and
pseudonyms for research team
and design partners to explicate
differing opinions, agency for
design decisions, and how the
research team reached these
decisions
• We report the design study using pseudonyms for the
research team and design partner
• We provide details on the research team and design
partner’s educational background, prior experience,
expertise, and interests
• We share unflattering details on the collaboration
between the research team and the design partner
design
activities,
evaluation
activities, and
decision
making.”
(cf. Schultze,
2000; Van
Maanen, 2011)
• Providing details on research
team and design partner that are
relevant for the DSR study (e.g.,
age, educational background,
experience, expertise, etc.)
• Exposing honestly and truthfully
even unflattering details of the
design process, e.g., mistakes
made amidst the design
• Sharing details on the messy and
less-than-optimal conditions of the
design process
including conflicts of interest and the design partners’
actions suggesting lack of confidence in the research
team’s abilities to interact with the design partner’s
customers
• We share details on our initial struggles to understand
and address the posed problem and its connection to
prior literature as well as messy parts and conflicts of
interest between the research team and design
partners during design and evaluation activities
Interlacing
design and
confession
“Reporting the
confessions on
the design
process, design
artifact and
design
evaluation not
separately but
in one
compound
report.”
(cf. Schultze,
2000)
• Interlacing self-reflexive and
confessional details with
descriptions of the design artifact
and its evaluation, i.e., process
and product (artifact)
• Interlacing methodological
guidelines for DSR with
descriptions of the actual design-
and research process
• Confine self-reflections and
confessional details to accounts
relevant for the design artifact’s
emergence
• We reveal details on our own and the design partner’s
actions, interests, considerations, and mistakes as part
of our description of the design process and the
resulting design artifacts.
• In the results section, we interlace the design process
and artifact descriptions with confessional accounts
relevant to the respective descriptions
• In the research approach and findings section, we
interlace definitions of core concepts of DSR and
methodological guidelines with descriptions of how we
used and followed these concepts and guidelines as
well as how we reconciled tensions between textbook
advice and the unfolding of the actual design and
research process
Designer–
researcher
stance
“Shifting
between the
attached
designer
viewpoint and
the detached
researcher
viewpoint.”
(cf. Van
Maanen, 2011)
• Describing the pre-understanding
of the design problem and
defining the eventually addressed
design problem
• Describing the research interest
• Presenting new design knowledge
and the design artifact
convincingly and in detail while
showing the ability to maintain
criticality to one’s own design.
• We describe our initial problem understanding as well
as how our problem understanding developed in
interactions with the design partner. These accounts
reveal how we continuously shifted between a
designer/researcher stance when considering the
problem and possible design solutions
• We revealed our research team’s research interest as
well as our considerations on what seemed to be the
design partner’s interest in the DSR project
• We present the BC approach for SMEs in great detail,
illustrating that it fulfils the defined MRs and providing
details for its application and use. At the same time, we
evaluate it critically and share details on this
evaluation, including its critical parts and pinpoint
future improvements.
Artless
ingenuity
“Demonstrating
that the design
artifact
emerged from a
design process
that features
the murkiness
and messiness
typical for
DSR.”
(cf. Van
Maanen, 2011)
• Illustrating that the design rests on
prior knowledge, the practical
problem space, and the
experimental nature of the design
process
• Providing the relevant details on
data collection and analysis (e.g.,
mode of data collection, length of
project, access to data, closing
the DSR project, and different
participants’ roles)
• Presenting the confessional and
design artifact details within the
structure of a canonical DSR
process
• Aligning less than-optimal
conditions for solving the faced
design problems with common,
everyday experiences
• We illustrate that the design partner approached us
defining the practical problem space and that we
grounded the MRs for addressing this problem space
in prior knowledge on BC and BC within SMEs.
• In the Research Approach section, we provide details
on the data collection techniques and how we analyzed
the data. We describe how we gained access via the
design partner, which role we and the design partner
assumed and how we continued the DSR project once
the design partner considered the artifact mature.
• We present our design process, the design artifact,
and the confessional details on their emergence within
the structure of an acknowledged and well established
DSR process model (Kuechler & Vaishnavi, 2008).
• We express how we tackled the struggles and conflicts
of interest with the design partner, providing reflections
on the design process and elaborating our actions and
trade-offs between sustaining the collaboration and
rigor.
Author biographies:
Jonna Järveläinen is a university lecturer of Information Systems Science in Turku School of
Economics at University of Turku, Finland and an adjunct professor in Faculty of Information
Technology at University of Jyväskylä, Finland. Her research interests lie in business
continuity management, game-based learning, educational escape rooms and collective
mindfulness. Her research has been published for example in International Journal of
Information Management and International Conference on Information Systems.
Marko Niemimaa is an associate professor at the University of Agder and an adjunct professor
at the University of Turku. His research focuses on the organizational aspects and implications
of cybersecurity and philosophical aspects of IS research including sociomateriality. His work
has been published in top-tier IS outlets, such as Journal of the Association for Information
Systems, European Journal of Information Systems, International Journal of Information
Management, DATA BASE, Communications of the Association for Information Systems, and
Computers & Security.
Markus P. Zimmer is a postdoctoral researcher in Information Systems at the Leuphana
University Lüneburg, Germany and a visiting researcher at the University of Turku, Finland.
Markus studies digital technology, organizational change and strategy. He is particularly
interested in responsible artificial intelligence, digital transformation and sustainability
development. His work has been published in several peer-reviewed outlets including
Information Systems Frontiers and Scandinavian Journal of Information Systems.
