A Practical Method to Plan Co-Evolution of Business and Information

Technology

Sara Nodehi

1 a

, Tim Huygh

1 b

, Laury Bollen

1 c

and Joost Visser

2 d

Information Science, Open University, Heerlen, The Netherlands

LIACS, Leiden University, Leiden, The Netherlands

Keywords:

Software Evolution, Digital Business Strategy, IT Strategy, Business-IT Alignment, Design Science.

Abstract:

In our fast-changing digital world, Business-IT alignment is not about reaching an end state where business

and IT are aligned but about continuously adapting both IT and business to remain aligned with each other.

Currently, managerial instruments for doing so are lacking or disconnected. We aim to provide a light-weight

and easy-to-use managerial tool for regular re-alignment and co-evolution of organisational goals and soft-

ware assets for technical and business-oriented stakeholders. Using a Design Science Research approach, we

designed our planning method by conducting exploratory interviews to establish its requirements, reviewing

pre-existing instruments, expanding upon them, and integrating them into a single planning process. As a

result, we created a 5-step method for collaboratively creating, sharing, and monitoring so-called “evolution

plans” and evaluated it in an educational pilot and through conﬁrmatory expert interviews. Our method con-

tributes to emerging research that complements established theoretical models of business-IT alignment with

its practical operationalisation.

1 INTRODUCTION

Information technology (IT) is a key business en-

abler. As organisations adapt their business activities

to relentless changes in the commercial, regulatory,

and technology landscape, so must they adapt the IT

assets on which those activities rely (Visser, 2019).

While strategy, rather than technology, should drive

these changes (Kane et al., 2015), the business cannot

change faster than the IT assets allow (Burden et al.,

2018). Therefore, it is crucial that desired business

changes can be translated efﬁciently and effectively

to changes in IT assets, which is the domain of busi-

ness/IT alignment.

The alignment of business and IT has been the ob-

ject of study for over three decades (Coltman et al.,

2015), with a focus on understanding and explain-

ing the alignment as a phenomenon (Henderson and

Venkatraman, 1999), measuring the degree to which it

has been attained, and identifying its enabling factors

(De Haes and Van Grembergen, 2009).Yet, the ‘align-

https://orcid.org/0000-0002-2919-1336

https://orcid.org/0000-0003-4564-7994

https://orcid.org/0000-0001-6475-7561

https://orcid.org/0000-0003-0158-3095

ment of IT with Business’ remains a difﬁcult man-

agement issue (Kappelman et al., 2021). As recog-

nized by others (Karpovsky and Galliers, 2015), this

is caused in great part by the scarcity of research on

concrete operational methods that can be used to ef-

fectively establish or increase alignment.

In this paper. we describe a 5-step “evolution

planning” method to help operationalize business-IT

alignment. To develop the method, we followed a

design-science approach where an initial method was

reﬁned and evaluated through exploratory and conﬁr-

matory interviews and an educational pilot.

We start with related work in Section 2. We out-

line our research approach in Section 3. Section 4

lists the concrete challenges we identiﬁed and hope to

mitigate with our method. The method is described in

Section 5, and evaluated in Section 6. We conclude

with a summary and future work in Section 7.

2 RELATED WORK

Theoretical models have been proposed to under-

stand and explain the alignment phenomenon on the

level of entire organizations, most notably the semi-

nal Strategic Alignment Model (SAM) of Henderson

Nodehi, S., Huygh, T., Bollen, L. and Visser, J.

A Practical Method to Plan Co-Evolution of Business and Information Technology.

DOI: 10.5220/0011968000003467

In Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023) - Volume 2, pages 615-622

ISBN: 978-989-758-648-4; ISSN: 2184-4992

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

615

and Venkatraman (1999). SAM describes interrela-

tions among four business and IT components (i.e.,

business strategy, IT strategy, business infrastructure

and processes, and IT infrastructure and processes).

Luftman (2004) has proposed to quantify business/IT

alignment through a strategic alignment maturity as-

sessment, to measure its effects on ﬁrm performance

(Luftman et al., 2008), and has attempted to identify

inhibiting and enabling factors for alignment (Luft-

man et al., 1999).

While it is valuable to understand and explain

business/IT alignment, these insights do not provide

concrete operational tools to establish or increase

alignment. An early exception is the work by Avison

et al. (2004), who have expanded on SAM with a ‘uni-

ﬁed framework’ to assess, monitor, and modify align-

ment levels. This framework amounts to a project pri-

oritisation process, taking project proposals or reports

as input, that allows management to assign or adjust

project resources to enhance alignment. Still, Kar-

povsky and Galliers (2015) identiﬁed the lack of op-

erationalisation as an important remaining challenge

if alignment research is to have demonstrable practi-

cal relevance.

Arguably, Enterprise Architecture (EA) frame-

works can been seen as (collections of) instruments to

achieve business/IT alignment. Speciﬁcally, EA is in-

tended to facilitate communication between business

and IT stakeholders. However, EA frameworks are

experienced as theoretical, rather than practical, and

their full implementation is often seen as inadvisable

and infeasible (Gerber et al., 2007; Evernden, 2015;

Buckl et al., 2009). Kotusev et al. (2017) conﬁrmed

this view in a study among practitioners. Thus, EA

does not offer ready-to-use operational methods for

business/IT alignment.

In a more recent step towards the operationalisa-

tion of IT/Business alignment, Kotusev (2020) intro-

duces a decision-making pipeline with 5 phases that

are increasingly operational and detailed: positioning,

focusing, prioritizing, assessing, and implementing.

These phases are reconstructed on the basis of inter-

views with 29 IT planners, and descriptions are given

of actors, activities, and documents relevant in each

phase. Compared to this pipeline, our 5-step method

introduced below provides further operationalisation.

For operational methods that can contribute to

business/IT alignment, we can also look to compo-

nents of agile software development methodologies.

While, historically, agile methodologies were focused

on software development activities per se, the align-

ment of these activities with business needs is also

addressed, especially by frameworks for large-scale

agile development such as Large Scale Scrum (LeSS)

and the Scaled Agile Framework (SAFe). For exam-

ple, SAFe offers the notions of ‘portfolio vision’ and

‘strategic themes’ that are intended to connect the ag-

ile development activities to the larger business con-

text. While these notions give high-level guidance,

an operational method speciﬁcally focused on the

joint planning of (agile) business, and IT changes is

currently lacking. Furthermore, Conboy and Carroll

(2019) found that scaled agile frameworks are rarely

fully adopted, and even partial adoption typically en-

tails ample organisation-speciﬁc customisation of the

adopted elements. Thus, scaled agile frameworks are

in practice used as toolkits from which organisations

use those elements that suit them most.

Thus, while traditional Business/IT alignment re-

search still suffers from lack of concrete operational-

isation, Enterprise Architecture and large scale Agile

software development fail to adequately ﬁll this gap.

3 RESEARCH APPROACH

In our study, we have taken a design science research

approach, where the ambition is to design and eval-

uate an artifact (Hevner et al., 2004; Peffers et al.,

2007, 2006). Here, an artefact is for instance a model,

a method, a system, or any designed object that em-

bodies the solution to a problem. Within the IS ﬁeld,

design science has been applied in a wide variety of

research areas, including (service-oriented) systems

development (Keith et al., 2013), information security

education, training, and compliance (Silic and Lowry,

2020), and also in the context of strategic alignment

(Bourdeau et al., 2018). In our instantiation, the arte-

fact is a planning method and our research activi-

ties followed the 6-step design science process model

of Peffers et al. (2007).

1) Problem Identiﬁcation and Motivation and 2)

Deﬁnition of the Objectives for a Solution: To sharpen

our problem understanding and reach our solution ob-

jectives, we performed seven exploratory interviews

with practitioners (application context) and reviewed

relevant literature (knowledge context). For the in-

terviews, we selected people with medium to high

experience in roles on the interface of business and

IT. Given the exploratory nature of the interviews,

we aimed for a diversity of perspectives, rather than

representativeness. We invited 20 people from our

own professional network, of whom 7 were ultimately

found to be suitable and available. Two interviewees

had IT roles (Senior IT architect and DevOps engi-

neer), and 5 had more business-oriented roles (e.g.,

IT strategy consultant). The work experience of ﬁve

interviewees ranged between 4 and 6 years, while the

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

616

other two had about 17 years of experience.

After the interviews, transcripts were analysed

through qualitative coding, to interpret, organise, and

structure the recorded information. The results were

summarised in two main parts: challenges in organi-

sations regarding business and IT integration (prob-

lem identiﬁcation), and ingredients and constraints

for possible solutions that organisations use or think

can be useful for solving these challenges (solution

objectives). Apart from the solution directions iden-

tiﬁed in the interviews, we reviewed the literature

for solution elements that could be used as building

blocks for our planning method.

3) Design and Development: We set out to design

a new planning method with several constraints in

mind. Firstly, we want the method to enable commu-

nication and collaboration between IT and business-

oriented roles. Therefore, it must be usable and un-

derstandable by a broad range of stakeholders. Sec-

ondly, we want the method to be light-weight, i.e.,

executable with relatively low effort and in a short

time-span. This allows the method to be used quickly

and often, hence doing justice to the agility that or-

ganisations currently are pursuing. Finally, we want

the method to be applicable within a wide range of

companies, which means it cannot be tied to a spe-

ciﬁc business or technology domain, or to a speciﬁc

framework for business and IT development.

The ﬁrst design of the method was created by the

last author and then improved by the ﬁrst author by

providing more detail to several elements, adding new

elements, and clarifying terminology. In the remain-

der of the paper, we will describe the ﬁnal, improved

method and only occasionally, when relevant, refer to

the ﬁrst version of the method.

4) Demonstration and 5) Evaluation: We did the

evaluation phase in two steps to conﬁrm that our

method achieved its intended purpose. Firstly, the

(ﬁrst version of the) method was piloted in an edu-

cational setting. A total of 42 students were asked to

apply the method as part of two instances (2020 and

2021) of a course on ”Managing Software Evolution”

which is part of the master program ICT in Business

and the Public Sector. The pilot served to test the un-

derstandability and feasibility of applying the method.

Secondly, we evaluated our method in semi-

structured conﬁrmatory interviews with four of the

participants of our exploratory interviews. We pre-

pared a presentation of the method elements for these

interviews, interleaved with a worked-out example

(demonstration) that includes all elements. Each ele-

ment with accompanying example was presented dur-

ing the interview, followed by a number of structured

questions and an unstructured conversation.

The structured questions were drawn from vari-

ous technology acceptance models, focussing on de-

terminants for acceptance as found signiﬁcant in a re-

view of multiple methods by Riemenschneider et al.

(2002): ease of use (is using the element free of ef-

fort?), compatibility (is using the element consistent

with current ways of working?), subjective norm (is

using the element accepted by others, such as col-

leagues, supervisors, clients?), usefulness (does us-

ing the element enhance the interviewee’s job perfor-

mance) and intention (would the interviewee use the

element when an opportunity arises?).

6) Communication: A description of the method

and the template for its deliverable have been made

available under a permissive license in an open

repository. The process of designing and validating

the method have been published in a master’s the-

sis (Nodehi, 2022) and this paper.

4 ALIGNMENT CHALLENGES

AND SOLUTIONS

Exploratory interviews were held with seven experts.

Analysis of the interview transcripts through qualita-

tive coding provided us insights into challenges that

exist in organisations regarding business and IT inte-

gration, and possible solutions that organisations use

or think can be useful for solving these challenges.

Here we summarise the identiﬁed challenges.

• Lack of Strategy Implementation: Many inter-

viewees reported a persistent gap between formu-

lating a (digital) strategy and the reality of strategy

implementation. After a strategy is formulated, its

execution, i.e., translation to concrete actions and

desired outcomes, is experienced as highly chal-

lenging.

• Autonomous IT Teams’ Culture and Domi-

nance of Business Teams: Several interviewees

indicated that some IT teams give their own ob-

jectives precedent over the cooperation with busi-

ness stakeholders and over overall organisational

goals. This can result in overly sophisticated fea-

tures or over-engineered technical solutions that

are not useful or necessary. Conversely, intervie-

wees report that business teams often want to pur-

sue short-term ﬁnancial goals, constantly pushing

and asking the IT team to implement new fea-

tures and functionalities while disregarding less

urgent technical improvements. Over time, over-

ruling the IT people may cause problems and re-

sult in low-quality systems. We recognize this

phenomenon as technical debt (Li et al., 2015).

A Practical Method to Plan Co-Evolution of Business and Information Technology

617

• Diversity of Stakeholder Expectations: While

the involvement of stakeholders is recognised as

important and has increased, several interviewees

indicated difﬁculties in managing and aligning the

diversity of stakeholder expectations. This may

lead to misunderstanding or even ignoring some

stakeholder viewpoints, or to adopting disjoint ob-

jectives from multiple stakeholders within a sin-

gle strategy without appropriately connecting or

merging those objectives into a shared ambition.

• Lack of Digital Technology Awareness: Several

interviewees mentioned the challenge for organi-

sations to remain sufﬁciently updated about tech-

nological developments. The rapid pace of tech-

nological development makes it difﬁcult to be-

come aware and gain sufﬁcient knowledge of new

technologies as they arise, and to be able to take

timely advantage of them.

• Lack of Central Coordination: Several inter-

viewees mentioned a lack of central organisation,

ensuring coherence and a certain level of control

over the multitude of projects and initiatives that

are being considered or conducted throughout the

organisation. Lack of coordination leads to mis-

communication, delays, and redundant activities.

• Lack of Situation Analysis: Before starting new

projects organisations must look at the present

state of their business within the marketplace.

Though most organisations understand the neces-

sity, many are unable to perform such situation

analyses in sufﬁcient depth and at the right time.

• Need for Structural Changes: Some well-

known frameworks and models such as SAFe and

“the Spotify model” exist to remove the gaps be-

tween business and IT teams. But implementing

these models and frameworks is not an easy task

and requires structural changes in organisations.

• Problems Deﬁning a Clear, Focused, Shared

Goal: The importance of goal setting is evident to

every organisation. Organisations not only need

to set goals, but they also need to align individ-

ual goals to team goals and team goals to organ-

isational goals. Differences in goal deﬁnition be-

tween individuals and teams may cause conﬂicts

in some organisations and prevent them from im-

proving.

• Problems in Strategy Formulation: Organisa-

tions must formulate their strategy correctly to

achieve their goals and measure their level of at-

tainability. Since the world is changing rapidly

and emerging technologies are being entered into

the market faster than ever before, it is hard for

some organisations to adapt their strategy for-

mulation to the dynamic changes in the market,

which prevents them from being sustainable in the

market competition.

Apart from the above-mentioned challenges, in-

terviewees mentioned some possible solution direc-

tions for some of them, such as centralised strategy

formulation, deﬁning organisation-wide KPIs, pro-

viding training for employees to increase their aware-

ness, and translating strategic objectives to team-

speciﬁc targets. Some of these suggested solution di-

rections served as input for our method design.

5 THE PLANNING METHOD

Before designing our method, we reviewed existing

instruments, concepts, and techniques that may be

usable as components for our method. The existing

methods that we reused include: stakeholder analy-

sis (Kennon et al., 2009), SWOT and TOWS anal-

ysis (Weihrich, 1982), gap analysis (Marra et al.,

2017), design moves (Woodard et al., 2013), risk

management (Ahmed et al., 2007), roadmap (Kostoff

and Schaller, 2001) and logframe (Sartorius, 1991) .

Since these individual instruments are valuable and

well-known, our design approach has been to inte-

grate them into a coherent planning method.

Our planning method consists of a 5-step planning

process, conducted by a planning team through vari-

ous interactions with relevant stakeholders, leading to

a deliverable, called an evolution plan. An overview

of the process and the resulting deliverable are shown

in Figure 1. The evolution plan is created incremen-

tally in the ﬁrst three steps of the process, then vali-

dated in the fourth and disseminated in the ﬁnal step.

This plan typically takes the form of a set of presen-

tation slides, or a written report.

5.1 Planning Team

To lead the planning effort, a small team of about 2-4

members is formed. This team is tasked with driving

the planning process, interacting with various stake-

holders, and delivering the ﬁnal evolution plan. The

planning team members must be able to bridge busi-

ness and IT and have good interpersonal, analytical,

and communication skills. Product owners, product

managers, business analysts, and IT strategy consul-

tants are typically well-suited for this role.

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

618

Figure 1: The planning method. An Evolution Plan is created, validated, and disseminated in a 5-step process (left). The

deliverable (center) consists of various components (right), as illustrated with labels and questions.

5.2 Step 1: Set Ambition

In the ﬁrst step of the planning process, the ambition

of the evolution needs to be set. The planning team

ﬁrst assesses the current situation through interviews,

document review, and possibly technical inspection of

current systems and processes to derive the ambition.

This leads to a succinct description of the current sit-

uation in organisational terms (e.g., key stakeholders,

cost and revenue of current services, competitive po-

sition, regulatory concerns) and technical terms (e.g.,

system architecture, technical debt, quality of devel-

opment and deployment processes).

Secondly, the team conducts a SWOT (and pos-

sibly TOWS) analysis in collaboration with se-

lected stakeholders to clearly identify and describe

strengths, weaknesses, opportunities, threats, and

their interconnections. Typically, the SWOT is cre-

ated through short workshops, which are initiated by

reﬂection on the described situation. Thirdly, a list of

(strategic) goals is drafted, where each goal relates to

elements of the SWOT, and is linked to speciﬁc ben-

eﬁts for speciﬁc stakeholders. Also, for each goal,

the gap with the current situation is analysed. This

is done by describing the gaps, categorising them as

performance gap, proﬁt gap, market gap, etc., and list-

ing possible solution directions. Finally, (a selection

of) the goals are summarised into a single ambition

statement. The ambition statement should preferably

be a single sentence, formulated to be understand-

able to all stakeholders. Also, the ambition should be

quantiﬁed (measurable) and time-bound. The deﬁned

horizon for the ambition will typically be between 12

and 18 months, depending on what is appropriate in a

given organisational context.

5.3 Step 2: Deﬁne Evolution Steps

In the second step, the planning team deﬁnes a (lim-

ited) set of course-grained evolution steps from the

current situation to a to-be situation that fulﬁlls the

overall ambition. These evolution steps take the form

of design moves in the sense of “discrete strategic ac-

tions that enlarge, reduce, or modify a ﬁrm’s stock

of [digital artifact] designs” (Woodard et al., 2013).

To deﬁne design moves, the team may reﬂect upon

the gap analysis and possible solution directions for

each gap. Examples of design moves are adding a

new functional module to a software system, adding

an interface, separating out core functionality into a

reusable library, exposing conﬁguration parameters to

users, deployment onto a new infrastructure, or re-

moving support for little-used export/import formats.

A design move is given a short name for future

reference, and is deﬁned by a concise description and

a number of attributes. Its strategic intent explains

its rationale in relation to the ambition and/or the for-

mulated goals. Its measure of success is a quantitative

A Practical Method to Plan Co-Evolution of Business and Information Technology

619

‘deﬁnition of done’, i.e., a criterion or metric that clar-

iﬁes what constitutes successful completion of the de-

sign move. Also, a design move is decomposed into a

set of actions that can be assigned to speciﬁc roles or

teams. A cost estimation, is given of required effort

and possibly other resources (e.g., purchase of a soft-

ware licence) or inputs (e.g., agreement with a busi-

ness partner). Finally, risks and mitigations discuss

adverse events that may impede the completion of the

design move with an estimate of their likelihood and

possible mitigating actions.

The responsibility for deﬁning the design moves

lies with the planning team, who must do so on the

basis of input from stakeholders. This is a design ac-

tivity that is best conducted in an interactive or itera-

tive fashion, where design moves are drafted on ini-

tial input, then presented for discussion and review,

adjusted based on feedback, until a satisfactory set of

design moves has emerged. Care must be taken to de-

ﬁne design moves at a course level of abstraction. A

good heuristic is about 3-7 design moves, where each

design move comes with up to 5 associated actions.

5.4 Step 3: Compose the Evolution Plan

The third step of the evolution planning process is

to compose the complete evolution plan out of the

elements that have been deﬁned so far. From the

various design moves and their constitutive actions,

a roadmap is derived, where evolution steps are put

onto a timeline. The items on the roadmap can be the

design moves themselves, their constituting actions,

or a combination of these. Building a timeline starts

with analysing dependencies between roadmap items.

These dependencies then determine whether items

can occur simultaneously, or must be executed con-

secutively. Also, required effort and resource avail-

ability are taken into account to determine the place

of each item on the timeline.

Optionally, the roadmap can be supported with

two additional overviews: (i) a risk mitigation matrix,

where risks and the effects of mitigating actions on

their impact and likelihood are displayed in a matrix,

and (ii) a beneﬁt mapping that shows for each design

move and/or action which stakeholders are beneﬁted

and which carry responsibility for their realisation.

Once the roadmap has been deﬁned, all elements of

the evolution plan are in place and supplemented with

a (single-slide) executive summary.

5.5 Step 4: Validate the Evolution Plan

In the fourth step of the evolution planning process,

the evolution plan is distributed and/or presented to

various stakeholders for review, validation, and pos-

sible adjustment. This wide-loop explicit validation

step comes on top of any tight-loop validation activ-

ities carried out throughout the earlier steps. In case

validation leads to uncovering fundamental problems

in the plan, the process needs to return to the start.

Otherwise, minor imperfections can be ironed out be-

fore proceeding.

5.6 Step 5: Facilitate Initiation and

Monitoring

The last step of the planning process is to set the evo-

lution plan in motion. The planning team delivers the

ﬁnal report of the plan to the decision-making unit

(DMU), followed by a presentation and a discussion

of the plan with the DMU. This allows the DMU to

approve the plan and commit to its execution, typi-

cally by initiating a dedicated project or program, or

requesting the plan to be merged into ongoing trans-

formation activities. Optionally, a logframe is con-

structed to facilitate monitoring of progress, results,

and beneﬁts during the execution of the plan.

To support the evolution planning process, we

have created a number of supporting resources, avail-

able under CC-BY-SA licence

, such as a multi-tab

spreadsheet that supports incremental data collection,

a template report which includes presentation guide-

lines and instructions on how to instantiate the tem-

plate, an example report of a ﬁctional case and a man-

ual explaining how to conduct the evolution planning

process and use the various resources throughout.

The planning method that we propose addresses

a number of the alignment challenges mentioned in

Section 4. Lack of strategy implementation is ad-

dressed by the explicit linking of proposed design

moves and actions to the overall ambition, and by

specifying beneﬁts for each stakeholder, motivating

their involvement. Autonomous IT teams and the

dominance of business teams are addressed by the

collaborative nature of the planning process, where a

cross-functional planning team helps to balance both

sides. The diversity of stakeholder expectations is

managed through stakeholder analysis and the map-

ping of beneﬁts to stakeholders. Shared evolution

plans improve central coordination. Lack of situa-

tional analysis is counteracted through analysis of the

current situation supported by stakeholder and SWOT

analysis. Using the planning method does not rely

on the implementation of a comprehensive framework

that requires structural organisational changes. The

formulation of a shared ambition in an evolution plan

https://github.com/jstvssr/evolution-plans

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

620

establishes a clear, focused, and shared goal. Finally,

evolution plans help with strategy formulation in a dy-

namic environment, as the method is light-weight and

can be conducted rapidly and frequently.

6 EVALUATION

We ﬁrst evaluated understandability and feasibility to

apply our planning method by piloting it in an educa-

tional setting. Some optional elements of the method

were not included in the pilot, such as TOWS analy-

sis, stakeholder analysis, and gap analysis. A rubric

was used to grade the evolution plans delivered by

the students, covering the correct application of each

method element, internal consistency of the entire

evolution plan, and presentation clarity. According to

our observations, students quickly understood and ap-

plied the method in a limited time with good results,

which supports its understandability and feasibility.

Secondly, during conﬁrmatory expert interviews,

we presented and demonstrated all the method ele-

ments to the interviewees, and their qualitative and

quantitative feedback was collected based on the tech-

nology acceptance criteria mention in Section 3.

According to our observations, interviewees per-

ceived most elements such as SWOT, TOWS, the

stakeholder analysis, risk mitigation matrix, and the

executive summary as easy to use. They found the

ambition and roadmap less easy to use, and the mon-

itoring element (logframe) somewhat difﬁcult to use.

Most of the elements were found compatible

with interviewees’ current working styles, and inter-

viewees thought other people in their organisations

would also accept using them (subjective norm). In

general, they thought that the ambition element would

not be accepted in their organisations. Possibly, stat-

ing an ambition in a concise and high-level manner

is feared to be too confronting in complex corporate

environments. A tactic by employees or consultants

in these environments may be to lay low and not state

the ambitions quite as unitary, but rather state multiple

goals such that multiple stakeholders can recognise

their own ambition in the list. Given the challenges

enumerated in Section 4, we however posit that crisp

ambition setting is a key success factor for alignment.

Although interviewees mentioned that most ele-

ments directly would improve their performance (use-

fulness), they thought that some elements such as am-

bition, stakeholder beneﬁts, and monitoring matrix

would not make them more effective. They expressed

mostly strong intention to use all elements except am-

bition and monitoring.

In short, while the education pilot demonstrated

the feasibility of our method, the conﬁrmatory inter-

views provided indications that the overall method

is deemed to be useful, though some elements (e.g.,

monitoring matrix) are considered hard to use or not

very compatible with current ways of work, and other

elements having low usability (e.g., ambition). Fur-

ther evaluation is needed to follow up on these results.

7 CONCLUSIONS

We designed and evaluated a concrete lightweight

operational method for planning the co-evolution of

business and information technology, with the aim

of bringing the Business/IT alignment ﬁeld forward

from abstract, macro-level insights to pushing for-

ward the micro-foundations of the ﬁeld. We have ini-

tiated the evaluation of our method, now however still

limited to an educational pilot and expert interviews.

The interviews were limited in the role and number

of interviewees, lack of internationalization, and gen-

der bias. Therefore, further evaluation is required to

capture a broader range of perspectives. Currently,

we are setting up case studies in various organisations

to evaluate the method’s applicability in the ﬁeld, to

shed a light on the actual effects of using the method,

where the question arises whether businesses or busi-

ness units that employ the method can achieve im-

proved alignment, as measured e.g., by the strategic

alignment maturity model of Luftman (2004).

REFERENCES

Ahmed, A., Kayis, B., and Amornsawadwatana, S. (2007).

A review of techniques for risk management in

projects. Benchmarking: An International Journal,

14(1):22–36.

Avison, D., Jones, J., Powell, P., and Wilson, D. (2004).

Using and validating the strategic alignment model.

Journal of Strategic Information Systems, 13(3):223–

246.

Bourdeau, S., Hadaya, P., and Lussier, J.-E. (2018). As-

sessing the strategic alignment of information sys-

tems projects: A design science approach. Projec-

tics/Proyectica/Projectique, 20(2):115–154.

Buckl, S., Ernst, A., Lankes, J., Matthes, F., and Schweda,

C. (2009). State of the art in enterprise architecture

management. Munich, Germany: Software Engineer-

ing for Business Information Systems (SEBIS).

Burden, A., Van Der Ouderaa, E., Venkataraman, R.,

Nystr

om, T., and Shukla, P. P. (2018). Technical debt

might be hindering your digital transformation. MIT

Sloan Management Review, 60(1):1–5.

Coltman, T., Tallon, P., Sharma, R., and Queiroz, M. (2015).

Strategic it alignment: twenty-ﬁve years on.

A Practical Method to Plan Co-Evolution of Business and Information Technology

621

Conboy, K. and Carroll, N. (2019). Implementing large-

scale agile frameworks: challenges and recommenda-

tions. Ieee Software, 36(2):44–50.

De Haes, S. and Van Grembergen, W. (2009). An ex-

ploratory study into it governance implementations

and its impact on business/it alignment. Information

Systems Management, 26(2):123–137.

Evernden, R. (2015). The architect role-what kind of ar-

chitect are you? Journal of Enterprise Architecture,

11(2):28–30.

Gerber, S., Meyer, U., and Richert, C. (2007). EA Model as

central part of the transformation into a more ﬂexible

and powerful organisation. In Reichert, M., Strecker,

S., and Turowski, K., editors, Enterprise modelling

and information systems architectures – concepts and

applications, pages 23–32, Bonn. Gesellschaft f

ur In-

formatik.

Henderson, J. C. and Venkatraman, H. (1999). Strate-

gic alignment: Leveraging information technology

for transforming organizations. IBM systems journal,

38(2.3):472–484.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).

Design science in information systems research. MIS

quarterly, pages 75–105.

Kane, G. C., Palmer, D., Phillips, A. N., Kiron, D., Buckley,

N., et al. (2015). Strategy, not technology, drives dig-

ital transformation. MIT Sloan Management Review

and Deloitte University Press, 14(1-25).

Kappelman, L., McLean, E. R., Johnson, V. L., Torres,

R., Maurer, C., Kim, K., Guerra, K., and Snyder, M.

(2021). The 2020 sim it issues and trends study. MIS

Quarterly Executive, 20(1).

Karpovsky, A. and Galliers, R. D. (2015). Aligning in prac-

tice: from current cases to a new agenda. Journal of

Information technology, 30(2):136–160.

Keith, M., Demirkan, H., and Goul, M. (2013). Service-

oriented methodology for systems development. Jour-

nal of Management Information Systems, 30(1):227–

260.

Kennon, N., Howden, P., and Hartley, M. (2009). Who re-

ally matters?: A stakeholder analysis tool. Extension

Farming Systems Journal, 5(2):9–17.

Kostoff, R. N. and Schaller, R. R. (2001). Science and tech-

nology roadmaps. IEEE Transactions on engineering

management, 48(2):132–143.

Kotusev, S. (2020). The hard side of business and it align-

ment. IT Professional, 22(1):47–55.

Kotusev, S., Singh, M., and Storey, I. (2017). A

frameworks-free look at enterprise architecture. Jour-

nal of Enterprise Architecture, 13(1):15–21.

Li, Z., Avgeriou, P., and Liang, P. (2015). A systematic

mapping study on technical debt and its management.

Journal of Systems and Software, 101:193–220.

Luftman, J. (2004). Assessing business-it allignment matu-

rity. In Strategies for information technology gover-

nance, pages 99–128. Igi Global.

Luftman, J., Dorociak, J., Kempaiah, R., and Rigoni, E. H.

(2008). Strategic alignment maturity: a structural

equation model validation. AMCIS 2008 Proceedings.

Luftman, J., Papp, R., and Brier, T. (1999). Enablers and

inhibitors of business-it alignment. Communications

of the Association for information Systems, 1(1):11.

Marra, M., Di Biccari, C., Lazoi, M., and Corallo, A.

(2017). A gap analysis methodology for product life-

cycle management assessment. IEEE Transactions on

Engineering Management, 65(1):155–167.

Nodehi, S. (2022). A methodology for integrated business-

technology planning. Master’s thesis, LIACS, Leiden

University.

Peffers, K., Tuunanen, T., Gengler, C. E., Rossi, M., Hui,

W., Virtanen, V., and Bragge, J. (2006). The design

science research process: A model for producing and

presenting information systems research. In First In-

ternational Conference on Design Science Research

in Information Systems and Technology, pages 83–16.

Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-

terjee, S. (2007). A design science research method-

ology for information systems research. Journal of

management information systems, 24(3):45–77.

Riemenschneider, C. K., Hardgrave, B. C., and Davis, F. D.

(2002). Explaining software developer acceptance

of methodologies: a comparison of ﬁve theoretical

models. IEEE transactions on Software Engineering,

28(12):1135–1145.

Sartorius, R. H. (1991). The logical framework approach to

project design and management. Evaluation practice,

12(2):139–147.

Silic, M. and Lowry, P. B. (2020). Using design-science

based gamiﬁcation to improve organizational security

training and compliance. Journal of Management In-

formation Systems, 37(1):129–161.

Visser, J. (2019). The world is eating your software. Cutter

Business Technology Journal, 32:10–14.

Weihrich, H. (1982). The tows matrix—a tool for situa-

tional analysis. Long range planning, 15(2):54–66.

Woodard, C. J., Ramasubbu, N., Tschang, F. T., and Samba-

murthy, V. (2013). Design capital and design moves:

The logic of digital business strategy. MIS Quarterly,

pages 537–564.

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

622