Content uploaded by Dina A. Elikan
Author content
All content in this area was uploaded by Dina A. Elikan on Jan 11, 2018
Content may be subject to copyright.
Designing Tools for Collectively Solving Ill-Structured Problems
Hazbi Avdiji
Faculty of Business and
Economics, University of
Lausanne
hazbi.avdiji@unil.ch
Dina Elikan
Faculty of Business and
Economics, University of
Lausanne
dina.elikan@unil.ch
Stéphanie Missonier
Faculty of Business and
Economics, University of
Lausanne
stephanie.missonier@unil.ch
Yves Pigneur
Faculty of Business and
Economics, University of
Lausanne
yves.pigneur@unil.ch
Abstract
Ill-structured management problems are of
paramount importance for organizations today. As they
are complex to solve, they are undertaken by teams of
diverse individuals who make use of tools to help them in
solving such problems. Most tools either focus on
supporting collaborative practices or are dedicated to
solving specific ill-structured problems. In this paper, we
bridge these two perspectives and provide design
principles for tools that both support collaboration and
are tailored for specific ill-structured problems. We
derived these design principles from our participant
observation of two critical cases of such collaborative
tools: the Business Model Canvas and the Team
Alignment Map. We lay the theoretical and design
foundations for future developments of similar
collaborative tools. Our paper illustrates the value that
the IS discipline can bring to the increasing call for a
design approach to management by rigorously
developing tools for co-design.
1. Introduction
As today’s business reality is characterized by ill-
structured, complex, and intangible management
problems, work is increasingly carried out by teams of
individuals [1],[2]. The potential of teams to solve such
problems lies in the diversity of its member who
contribute with their different backgrounds, knowledge
domains, and expertise [3]. This potential has been
acknowledged for various ill-structured management
problems such as strategic management [4], [5]
information systems development [6], [7] and new
product development and service design [8],[9],
[10],[11].
Collaboration is heavily mediated by tools and
objects that are used by teams for the purpose of
managing this diversity [12]. Therefore, there has been
extensive research on collaborative tools and systems in
disciplines such as Information Systems [13],
Organization Studies [14], and Computer-Supported
Cooperative Work [15]. Such tools can take on many
forms such as conceptual models, procedures, material
artifacts, and information systems. Most contributions
of these research strands resulted in collaborative tools
and systems that facilitate the creation of a shared
understand rising between diverse individuals
(e.g.,[16],[17],[18]) facilitate communication and
information exchange [19] support synchronous and
asynchronous coordination between individuals (e.g.,
[20],[21]), and enhance group creativity (e.g.,[22],
[23]).
While these tools have proven valuable to facilitate
the process of collaboration, they do not directly support
individuals in solving specific management problems.
These tools are not tailored to the resolution of a certain
classes of problems but have generic supportive
functions. For example, when teams face the ill-
structured problem of executing and coordinating a plan
of actions, they use a collection of objects and tools to
solve it [24] as there is no tool that is specifically
dedicated to that problem. The reliance on such a
collection of objects and tools is not as effective and
practical as relying on one tool and it increases the risk
of divergence within team members [25].
In parallel, a survey conducted by Rigby & Bilodeau
[26] outlined that the tools most used by practitioners
are tools that are dedicated to specific problems such as
Total Quality Management, project planning, or
strategic analyses. However, these tools remain
analytical and even though they can be used by multiple
individuals, they do not necessarily support a
collaborative problem-solving and design approach
which is crucial when teams face ill-structured problems
([27], [28]).
In this paper, we seek to bridge both these
conceptions of tools by asking the following question:
How to design collaborative tools that are tailored for
specific ill-structured problems?
Proceedings of the 51st Hawaii International Conference on System Sciences |2018
URI: http://hdl.handle.net/10125/49940
ISBN: 978-0-9981331-1-9
(CC BY-NC-ND 4.0)
Page 400
We contribute to this question by proposing three
design principles that lay the foundations for designing
tools that support teams in collectively solving specific
ill-structured problems. To do so, we performed
longitudinal participant observation of the design
process of two cases of such tools: (1) the Business
Model Canvas that helps teams collectively solve
strategic and business modeling problems and (2) the
Team Alignment Map that supports teams in collectively
solving the problem of coordination and execution. We
use the cases as illustrations, because both were initially
conceptual models for the specific problems they address
and have iteratively been evolved into paper-based
collaborative tools. Understanding the foundational
principles of such collaborative tools allows us to build
a solid ground from which future Computer-Aided
Design (CAD) tools could be developed
2. Literature review: Tools in collaboration
Management is increasingly organized around teams
solving ill-structured problems such as information
systems development [6],[7], strategic management
[29],[5], project scope definition [30], knowledge
management [31], new product development and service
design [8],[9],[10],[32] work organization and
coordination [33],[2], and customer journey design [34],
[35]. These problems are complex to solve as they are ill-
defined, difficult to frame, have ambiguous or unstable
requirements, have various potential solutions, are often
intangible and involve multiple and different
stakeholders [36], [37], [38]. There is often limited
consensus as of the appropriate solution, disagreement
on how to proceed and no clear formulation of the
problem itself [39].
Teams make use of a variety of tools and objects to
augment their capabilities when navigating through such
complexity [23],[12],[40]. Collaborative tools support
collaboration by serving different purposes such as
directing information sharing, augmenting the team
members’ capabilities to carry out certain tasks, directing
and aligning work, enhancing inquiry and idea
generation, guiding the perception and understanding of
the problem at hand, motivating participation and
cooperation [23],[14],[41].
Teams make use of such collaboration-support
capabilities by using a collection of tools when solving
ill-structured problems [24]. Depending on the stage of
problem-solving they are in, team members use different
configurations of tools [42],[40]. Some objects and tools
will be used when framing the problem such as those that
help teams create a shared understanding of their
situation and revealing the interdependencies between
team members while others will be used when solving
the problem by helping them organize activities and
coordinating their contributions [41]. However, Seidel
and O’Mahony [25], found that using different tools and
objects for solving a problem might lead to disunity
within the team and ineffective collaboration as
different objects create different understandings and
representations, especially if they are not used by all
team members across time.
Teams also use problem-support tools that address
specific management problems. Such tools are in the
form of conceptual artifacts that guide practitioners’
reflection (e.g., the SWOT analysis, the strategic
alignment model). However, these tools remain purely
analytical and are not designed for collaborative use
which proves problematic in the context of ill-structured
problems which require collaboration of diverse
individuals [27], [43].
These two strands of research suggest that there is a
need for practitioners to use tools that both support
collaboration and help them solve specific ill-structured
problems. These needs have led to a recent generation
of tools that guide collaboration for specific ill-
structured problems that were inspired by the Business
Model Canvas [55]. Such tools reconcile both streams
of research on tools - those that focus on collaboration
support and those that focus on management problems -
and propose a paradigm shift.
Tools such as the Project Canvas [44] or the
Customer Journey Mapping Game [45] reuse the visual
aspects of the Business Model Canvas in which
dimensions of a problem are displayed as empty boxes
that team members collaborate to fill using sticky notes.
Except for the Business Model Canvas, it is not clear
how theoretically and conceptually sound their
components are as they have mostly been designed only
by business practitioners. This proves problematic as
these components shape how team members frame a
problem, which might lead to ineffective problem-
solving. In other words, we need design principles
which would support the rigorous design of such tools.
Therefore, the following question arises: How to design
collaborative tools that are tailored for specific ill-
structured problems?
3. Methodology
To answer our research question, we relate two case
studies [46] of the design process of two collaborative
tools that support collaboration for two specific ill-
Page 401
structured management problems: the Business Model
Canvas for strategy and business modeling and the Team
Alignment Map for coordination and execution.
Both tools represent critical cases as they are among
the few representative examples of the collaborative
tools that our research questions target and were
designed based on theoretically sound and rigorous
academic works. Moreover, both tools have attracted
considerable interest by practitioners. The Business
Model Canvas is used by more than 5 million people
globally [47] and is arguably a quasi-standard in the field
[48] .The Team Alignment Map was developed in June
2016 and has since then attracted more than 400 requests
for proposals and training.
The selection of these cases was also motivated by
their potential for replication [49] as there are extensive
similarities and differences between the two cases
(Table 1). The cases are similar in that (1) both tools are
collaborative, (2) they address ill-structured
management problems, (3) were part of design science
research projects, (4) their design and evaluation
involved strong implication and participation of end-
users and practitioners in the design and evaluation of the
tools, and (5) the tools are similar in their use. The cases
are different in that (1) they do not address the same
problems as one focuses on business modeling while the
other is tailored to coordination and alignment, and (2)
they were developed independently by two different
teams.
Data on the design process of both tools was
collected through participant observations and a total of
10 interviews with the co-designers. The observation
ranged from September 2008 to November 2010 for the
Business Model Canvas, which consists of 470 hubs and
from September 2013 to this date for the Team
Alignment Map. Our observation also covers the periods
before the design of the tools which allowed us to gather
data on intermediary instantiations and artifacts that led
to the current versions of the tools.
The data analysis was performed by comparing the
design process of both tools. Similarities in the design
and the properties of the tools allowed us to define an
initial set of design principles for developing
collaborative tools that address specific ill-structured
problems. These principles were then refined by taking
into account the differences of the cases. Design
principles “define the structure, organization, and
functioning of the design product or design method”
[50].
As suggested by [51], design principles can be
validated by evaluating the artifact from which they
were drawn. We followed their guidelines and evaluated
the tools’ usefulness, efficacy, and usability. Moreover,
[52] and [53] suggest that the demonstration of rigor in
design can be evaluated through case studies.
4. Cases descriptions and evaluations
In this section, we describe both cases by outlining
the purpose of the two tools. We also relate the
evaluation of the tools.
4.1. The Business Model Canvas
The Business Model Canvas is a tool for business
model development [54] .The Canvas defines business
models to consist of nine components, and presents
these components through a visual template in the form
of a paper-based F1 poster to facilitate generating and
communicating business model ideas. In practice, the
Canvas has become the quasi-standard for describing
business models [50].
The Business Model Canvas is seen as essential for
entrepreneurs to keep a constant reflection and for
developing their business model [55]. Some go further
by stating that the Business Model Canvas is arguably
the most important tool for this purpose [7]. Moreover,
the tool has attracted tremendous interest in practice as
the designers of the tool state that more than 5 million
of the tool were made globally [47]. The impact of the
Canvas is not limited to practice as the book describing
the tool has been referenced by more than 5,000
academic studies according to Google Scholar.
Adding to that, Trimi and Bergebal-Mirabent., [55]
also states that the Canvas is useful for collaboration, as
it facilitates communication among stakeholders,
becoming the starting point of strategic discussion
around the business activities of the company.
4.2. The Team Alignment Map
The Team Alignment Map is the most recent
instantiation of a series of tools that are part of the same
design science research project. These instantiations
were all developed for the purpose of team coordination.
All instantiations are based on Clark’s psycholinguistic
theory on joint activities [56].
Page 402
Previous instantiations were validated and published
in an A-ranked IS journal and conference by the
designers [57], [58]. The Team Alignment Map was
recently tested in ten teams with seven informants, four
of whom were project managers and three were coaches
supporting the team.
The Team Alignment Map was perceived by the
seven interviewees as easy, simple, and straightforward
to use, hence providing evidence for the ease of use of
the tool.
All informants considered the tool as useful for their
teams to co-design their coordination as it allowed
everyone to take part actively in the discussions on the
four dimensions. One informant reported that using the
Map “is not so much filling it out and assigning roles and
responsibilities to people. It’s more ‘okay here are the
main points we need to make sure that we cover’”
Using the tool led all teams to conclude on a social
contract on the four elements of their joint activity.
One informant defined the Team Alignment Map as
“some sort of contract where everyone is saying ‘Okay,
I commit to this’. It’s in writing, it’s in front of us”.
Moreover, five out of seven informants said that he
tool easily allowed them to prototype different versions
of the Team Alignment Map as sticky notes were easy to
add, remove, and amend.
Overall, all the informants regarded the Team
Alignment Map as useful for co-designing coordination.
5. Cases analysis
We analyzed data from the development process of
both tools. Based on the similarities and the differences
between the two, we derive three design principles that
should inform the design of collaborative tools that
support teams in solving specific ill-structured
management problems (Table 1). Hereafter we describe
the three design principles and illustrate how we derived
them by describing the development process that took
place for both tools.
5.1. Design principle 1: Framing the ill-
structured problem through an ontology
The first design principle aims at framing the ill-
structured problem by developing an ontology with all
its elements and their relationships.
Design principle 1: Frame the ill-structured
problem by developing an ontology in which
the main components of the problem and their
relationships are modeled.
Ontologies allow to better define a problem as well
as its underlying concepts and relationships. As stressed
by [38], the most important and difficult task in a
Design Principle
Illustration in the Business Model
Canvas case
Illustration in the Team Alignment
Map case
Design principle 1: Frame the ill-structured
problem by developing an ontology in which
the main components of the problem and
their relationships are modeled.
Development of a “Business Model
Ontology” relying on the Ushold and
King (1995)’s methodology to build an
ontology from the existing literature
business modeling
Development of a conceptual model
translated from Clark (1996)’s theory
on coordination.
Design principle 2: Represent the ontology
into a shared visualization by deriving a
concept map from the ontology and
structuring the concepts logically into a
visual empty problem space.
Transforming the Ontology into the
Business Model Canvas, by deriving the
most important concepts from the
ontology and placing them into a visual
space.
Development of several visual artifacts
(cards, mobile application and maps)
that were tested by users. The Map with
blank spaces to allow users to fill them
during their meetings.
Design principle 3: Instantiate the
visualization into a shared support in order to
use it as a problem space on which solutions
can be prototyped. Sticky notes are used to
add, remove or change the content within
each empty space as the discussion unfolds.
The authors propose to print the paper-
based tool on a big format and to write
all the possible solutions for the
problems on sticky notes that will then be
placed on their corresponding problem
space.
The authors propose to print the paper-
based tool on a big format and to write
all the possible solutions for the
problems on sticky notes that will then
be placed on their corresponding
problem space.
Table 1. Design Principles for collaborative tools for solving ill-structured problems
Page 403
problem-solving activity is to provide structure to a
problem when there is none apparent. Among the
multiple means to structure a collaborative problem,
ontologies have long been used and proven valuable
when designing artifacts [59],[60]. It provides
participants with a collective frame to understand all the
elements they need to think of and discuss for a given ill-
structured problem [61]. Based on this structure,
participants can envision and collectively generate
different solutions. Thus, ontologies reduce conceptual
and lexical confusion by providing a unifying framework
within an organization [62].
The first step of the development of the Business
Model Canvas started with Osterwalder’s thesis [62] and
a first article [63] in which Osterwalder and Pigneur tried
to understand how business models could be described
and represented so that tools and concepts could be
developed for business modeling. To tackle this
question, they designed a rigorous conceptual model of
business models, which they called the Business Model
Ontology (BMO). The goal of this ontology was to
define the main components of business models and their
relationships.
To develop BMO, Osterwalder and Pigneur [63]
followed Uschold & King’s [64] methodology for
building ontologies: (1) they identified the key concepts
and relationships in the domain of business models, (2)
they produced precise and unambiguous text definitions
for the concepts and their relationships, (3) they
identified the terms to refer to these concepts and
relationships using labels. By following this process,
they identified nine elements (or building blocks) for the
business model ontology, which they represented as a set
of boxes which were related by arrows to depict their
relationships. Figure 1 shows this representation of the
different elements and how they relate to each other. The
nine building blocks all result from an extensive
literature review.
The design of the Team Alignment Map started with
a study published in an A-ranked journal in IS.. The aim
of the study was to develop an ontology for team
coordination based on Clark (1996)’s theory on joint
activities and coordination. The goal was to instantiate
his theory into a set of cards that project managers could
use as visual support during their team meetings to
remember the main elements they should discuss for
them to coordinate effectively.
The development of the Team Alignment Map’s
ontology was also based on prior literature. This
ontology proved valuable as it addressed the content of
conversations, unlike other accounts of coordination
that focus on organizational design or implicit
coordination[41].
5.2. Design principle 2: Representing the
problem structure into a shared visualization
The second design principle consists of developing
a visual representation of the ontology that is shared by
all participants so that they can all refer to the same
structure of the problem.
Design principle 2: Represent the ontology
into a shared visualization by deriving a
concept map from the ontology and structuring
the concepts logically into a visual empty
problem spaces.
Shared visualization focuses everyone’s attention on
a common frame. It helps avoid ambiguities in the
discussion and how the problem is framed and
understood between the stakeholders [65],[66]. If the
stakeholders use the semantics of the display to
configure their discussion, they decrease the risk of
semantic confusion and ambivalences [67]. The benefits
of visual templates, as compared to purely textual or
verbal communication modes, are to be found in their
structure, which offers a “representational guidance”
[61].
The Business Model Ontology was instantiated into
a shared visual tool, i.e. the Business Model Canvas
[54] (Figure 2). The most important components
unfolded during the ontology development were kept.
The relationships were used to set the order of the
different components. A conceptual map was built upon
the ontology, to relate all the concepts. The conceptual
map was the basis to the structure of the visual
instantiation. Concept maps have an additional level of
abstraction compared to ontologies which makes them
less complex to understand and use. The Canvas was
designed by the authors, having in mind the ontology
(i.e., the main concept and their relationships) but also
the goals of the instantiated tool. These goals included
(1) the business model tool should help business
Figure 1. Business Model Ontology
Page 404
practitioners understand a business model and the
relationships behind its elements more quickly, and (2) it
should create a common language to improve
communication between the stakeholders when
addressing business model issues [68]. One of the
hypotheses behind these goals was that a visualization
tool would improve the quality of communication
between stakeholders and allow them to co-design
business models more easily.
For the Team Alignment Map, Clark’s terminology
was deliberately translated into shorter concepts in order
to ensure the parsimony of a conceptual map. The
ontology of the Team Alignment Map was instantiated
into several artifacts among which a set of cards, a web
application, and the Team Alignment Map. These
intermediary artifacts were tested in different
organizations and settings [57], [58]. Results of the study
showed that repeated use of the cards during by the
project manager during team meetings to direct the
content of the team’s discussions helped reduce
coordination breakdowns and proved helpful for teams
to align their contributions effectively.
Despite that, the designers of the tool received
extensive feedback from users who stressed their
willingness not only to have visual support during team
meetings, but rather have a tool that would allow all
team members to define the content of the four
dimensions by filling them with elements. Therefore,
the current version of the tool represents the four
dimensions of the ontology as four empty spaces on a
printed F1 poster, ranging from left to right as they
should be addressed in this order during conversations
(Figure 3).
5.3. Design principle 3: Using the shared
visualization for co-design
The third design principle consists of using the to co-
design a solution to their ill-structured problem. Co-
design is an iterative process of inquiry and co-creation
Clark (1996)’s
requirements
for coordination
Mastrogiac
omo et al.
(2014)’s
conceptual
model
Description
1. Identification:
Two individuals
(A and B) must
identify r (the
joint purpose)
Variable:
Joint
objectives
What the participants
intend to do
together
2. Ability: it must
be possible for A
and B to play
their part in
fulfilling r
Variable:
joint
resources
What the participants
need to play
their part
Variable:
joint risks
What could prevent
participants from
playing their part
3. Willingness: A
and B must be
willing to play
their part in
fulfilling r
Variable:
joint
commitment
s
What participants
expect each other
to do
4. Mutual belief:
A and B must
each believe that
1, 2, 3, and 4 are
part of their
common ground
Process:
team
meetings
Seek evidence of
mutual
understanding for joint
objectives,
joint commitments,
joint resources,
and joint risks in team
meetings or
project-related
conversations
Table 2. Team Alignment Ontology
Figure 2. Business Model Canvas
Figure 3. Team Alignment Map
Page 405
in which team members tap on their diverse set of
knowledge, experiences, and insights to create an artifact
- be it conceptual or material - that participates in solving
their common problem [69],[70],[32]. The shared
visualization thus acts as a shared problem space for
collective contributions.
Design principle 3: Instantiate the
visualization into a shared support in order to
use it as a problem space on which solutions
can be prototyped. Sticky notes are used to add,
remove or change the content within each
empty space as the discussion unfolds.
Co-design has several benefits to address ill-
structured management problems: it allows teams to
make use of their diversity to generate better ideas, it
promotes a trial-and-error approach to solving the
problem, and it increases the level of commitment and
satisfaction with the solution [32].
Because the Business Model Canvas aims at helping
users co-design business models, its designers have
instantiated the nine elements of the business model
ontology as building blocks on a shared large print paper-
based canvas. As the Canvas is visualized by all
participants, the nine building blocks provide a structure
for group reflection and discussion in which all
participants actively and collaboratively participate.
Each block is depicted as an empty space that users
discuss and fill with sticky notes on which they write
elements of the solution of the organizations’ building
blocks. The sticky notes can easily be added, amended,
or removed as the group discussion and reflection
unfolds. The tool supports co-design as it allows team
members to jointly discuss and define the business model
problem they face, and discuss and explore alternative
solutions, as has been identified by Steen [11].
For the use of the Team Alignment Map, the
designers relied on some users’ insights and on the
theoretical accounts of coordination [33] and [2] and also
decided to prescribe the use of the tool with co-design
techniques. In fact, team coordination is an iterative and
discursive process when individuals need to coordinate
for new joint activities or when problems occur
[33]. The co-design technique that is promoted and
prescribed is collaborative design and prototyping using
sticky notes. Team members thus display the Team
Alignment Map either in the same meeting room in
collocated settings or as a shared document during online
meetings. All participants write what they think are the
joint objectives, commitments, resources, and risks on
sticky notes. Participants then aggregate all their ideas
and evaluate them during open discussions where they
negotiate which elements to keep, add, remove, or
amend. They prototype their coordination until a
mutually satisfactory solution is reached.
6. Discussion
The question we asked in this paper related to how
to design collaborative tools that are tailored to specific
ill-structured problems. Our results answer this question
by advising designers how to develop such tools.
More specifically, we suggest that ill-structured
problems would benefit from being well-framed and
solved collaboratively. We can do so by using an
ontology that defines the components of the problem
and their relationships. This ontology should then be
instantiated into a shared visualization where
components are represented as empty spaces and
arranged according to their relationships. This allows
individuals to fill the empty spaces with elements of the
solution they are co-designing. Using sticky notes can
prove practical as it allows team members to easily fill
the columns and remove or amend any elements as they
develop better alternatives or point out at
inconsistencies. This supports the trial-and-error inquiry
that characterizes co-design [54], [11].
As all participants all share the same visualization of
the problem and the sticky notes, which represent the
same solutions, they can easily assess the components
of the given problem and address any potential
inconsistencies. They can also model different solutions
on the same visual representation and compare them. In
summary, the shared representation supports
participants in discussing, analyzing and generating
ideas when co-designing solutions to ill-structured
problems.
While visualization can take on different forms [71]
our cases inform that visualization and the way the tool
is to be used are interrelated. In both cases, the designers
opted for a shared visualization in which concepts are
depicted as empty spaces so that team members could
use them as problem spaces in which they can co-design
solutions. This visualization type has also been noted by
Comi & Bresciani [72] as valuable for designing
solutions to problems. We consider this type of shared
visualization to be the differentiating point between both
cases and the other collaborative tools that we outlined
in the literature review. The two cases also inform us on
the need for parsimonious visualization to ensure ease-
of-use. Designers then need to find a balance between
the completeness of the ontology to be represented and
Page 406
parsimony. This balance can be reached through testing
and evaluation with practitioners.
We also note from our cases that developing
ontologies requires considerable effort and inquiry.
However, it is important that the ontologies be rigorously
developed and tested to ensure that the problem is
correctly represented. Designers can follow the
guidelines by Gomez-Pérez [73] who advises that
ontologies be assessed for their consistency,
completeness, and conciseness. We stress the importance
of this part as problem representation is the most critical
part in problem-solving [74]. Both our cases had
different strategies for developing their ontologies as the
Business Model Ontology was developed by the
designers of the tool based on an extensive literature
review, whereas because the field of collaboration was
already more mature, the ontology of the Team
Alignment Map was derived from Clark’s theory on
coordination.
Moreover, our study informs on the need for
evaluation. Both the Business Model Canvas and the
Team Alignment Map were tested and evaluated
iteratively: first for their ontology, then their
visualization and finally the techniques of usage. The
evaluation was also done in different settings and
contexts. Feedback from practitioners helps refine the
tool as long as its usefulness, usability, and efficacy are
not satisfactory.
Finally, our design principles cannot substitute for
one another. The three design principles are to be
considered by designers as fundamental requirements for
designing such collaborative tools. In fact, our design
principles appear to be extensively interrelated and their
value cannot be decomposed: they participate in creating
valuable artifacts only when combined. To some extent,
these principles could be regarded as the bridge between
both strands of collaborative tools that we outlined in the
literature review, i.e. those that support collaboration and
those that are tailored for specific management
problems.
7. Conclusion & Future Work
Our paper is to be regarded as the initial step toward
the generation of a “toolbox” to help management teams
co-design solutions mostly but not exclusively to ill-
structured problems. This toolbox could address a
variety of problems in which each problem would have
a tool dedicated to it. It is important to note that this
toolbox would not imply that all other collaborative tools
would be replaced, rather that it would come in support
whenever teams face specific problems. In the case of
well-structured problems, there already exists classical,
rational decision making tools. But design thinking
approaches are becoming increasingly popular even for
well-structured problems. Thus, we could also imagine
a new generation of tools for these types of problems,
even though it is less needed. [8]
The two ill-structured problems we presented are not
specific to one organization. Our design principles can
thus be replicated across organizations. Therefore, our
design principles could be replicated and tested for other
ill-structured projects such as co-designing brand
identities, business processes, or data quality
management. In that regard, our paper assists the recent
emergence of visually shared collaborative tools which
have stressed the need for practitioners to have such
tools.
We believe that the IS discipline has an important
and central role to play in this endeavor. In fact, the
cores of our three design principles - ontologies, shared
visualization, co-design - have seen extensive
developments but in different domains rather in
isolation from one another. Ontologies have long been
used in engineering and academic research.
Visualization has received increasing interest in the
business practice as the number of recent books on the
subject illustrate it. Finally, co-design has recently
emerged as a valuable approach to collaboration in
innovation and design thinking. Through its recent
tradition with design science research, the IS discipline
is familiar with all three domains, i.e. engineering
academic research, the business practice, and design
thinking. We thus join Osterwalder and Pigneur’s [27]
conclusion on the potential for our discipline to provide
management research and practice with collaborative
tools for co-design.
These tools could also be in the form of Computer-
Aided Design. Such tools would augment management
team’s capabilities to co-design solutions to ill-
structured problems. This underlines the importance of
first understanding the fundamental requirements and
the spirit of such tools, which we started to formulate
from paper-based tools.
We hope that our study will help both practitioners
and researchers develop new tools that would instill a
new way of managing and working. As various scholars
have called for design in management [8],[10], we
believe that tools developed based on our design
principles can help practitioners adopt a design
approach, even for those who are not familiar or trained
with co-design.
Page 407
8. References
[1] B. A. Bechky, “Gaffers, gofers, and grips: Role-based
coordination in temporary organizations,” Organ. Sci., vol. 17,
no. 1, pp. 3–21, 2006.
[2] H. Minssen, “Challenges of teamwork in production:
demands of communication,” Organ. Stud., vol. 27, no. 1, pp.
103–124, 2006.
[3] A. C. Edmondson and J.-F. Harvey, “Cross-boundary
teaming for innovation: Integrating research on teams and
knowledge in organizations,” Hum. Resour. Manag. Rev.,
2017.
[4] M. Bruce and J. R. Bessant, Design in business: Strategic
innovation through design. Pearson education, 2002.
[5] M. Sosna, R. N. Trevinyo-Rodríguez, and S. R. Velamuri,
“Business model innovation through trial-and-error learning:
The Naturhouse case,” Long Range Plann., vol. 43, no. 2, pp.
383–407, 2010.
[6] K. Dorst, “The core of ‘design thinking’and its application,”
Des. Stud., vol. 32, no. 6, pp. 521–532, 2011.
[7] T. John and D. Kundisch, “Why Fit Leads to Surprise: An
Extension of Cognitive Fit Theory to Creative Problems,”
2015.
[8] R. J. Boland Jr, F. Collopy, K. Lyytinen, and Y. Yoo,
“Managing as designing: lessons for organization leaders from
the design practice of Frank O. Gehry,” Des. Issues, vol. 24,
no. 1, pp. 10–25, 2008.
[9] T. Brown, “Change by design,” 2009.
[10] M. Gruber, N. De Leon, G. George, and P. Thompson,
“Managing by design,” Acad. Manage. J., vol. 58, no. 1, pp. 1–
7, 2015.
[11] M. Steen, “Co-design as a process of joint inquiry and
imagination,” Des. Issues, vol. 29, no. 2, pp. 16–28, 2013.
[12] K. K. Cetina, “Sociality with objects: Social relations in
postsocial knowledge societies,” Theory Cult. Soc., vol. 14, no.
4, pp. 1–30, 1997.
[13] J. F. Nunamaker Jr, R. O. Briggs, D. C. Derrick, and G.
Schwabe, “The last research mile: Achieving both rigor and
relevance in information systems research,” J. Manag. Inf.
Syst., vol. 32, no. 3, pp. 10–47, 2015.
[14] D. Nicolini, J. Mengis, and J. Swan, “Understanding the
role of objects in cross-disciplinary collaboration,” Organ. Sci.,
vol. 23, no. 3, pp. 612–629, 2012.
[15] G. Fitzpatrick and G. Ellingsen, “A review of 25 years of
CSCW research in healthcare: contributions, challenges and
future agendas,” Comput. Support. Coop. Work CSCW, vol. 22,
no. 4–6, pp. 609–665, 2013.
[16] E. A. C. Bittner and J. M. Leimeister, “Creating shared
understanding in heterogeneous work groups: Why it matters
and how to achieve it,” J. Manag. Inf. Syst., vol. 31, no. 1, pp.
111–144, 2014.
[17] R. Harper, “From I-awareness to we-awareness in CSCW:
A review essay,” Comput. Support. Coop. Work CSCW, vol.
25, no. 4–5, pp. 295–301, 2016.
[18] G. Mangalaraj, S. P. Nerur, R. Mahapatra, and K. H. Price,
“Distributed Cognition in Software Design: An Experimental
Investigation of the Role of Design Patterns and
Collaboration.,” Mis Q., vol. 38, no. 1, pp. 249–274, 2014.
[19] E. B. Kerr and S. R. Hiltz, Computer-mediated
communication systems: Status and evaluation. Academic
Press, 2013.
[20] S. Kudaravalli, S. Faraj, and S. L. Johnson, “A Configural
Approach to Coordinating Expertise in Software Development
Teams.,” MIS Q., vol. 41, no. 1, 2017.
[21] D. M. Thomas and R. P. Bostrom, “Team leader strategies
for enabling collaboration technology adaptation: team
technology knowledge to improve globally distributed
systems development work,” Eur. J. Inf. Syst., vol. 19, no. 2,
pp. 223–237, 2010.
[22] M. Bogers and W. Horst, “Collaborative prototyping:
Cross-fertilization of knowledge in prototype-driven problem
solving,” J. Prod. Innov. Manag., vol. 31, no. 4, pp. 744–764,
2014.
[23] P. Dalsgaard, “Instruments of inquiry: Understanding the
nature and role of tools in design,” Int. J. Des., vol. 11, no. 1,
2017.
[24] H. Scarbrough, M. Robertson, and J. Swan, “Diffusion in
the face of failure: The evolution of a management
innovation,” Br. J. Manag., vol. 26, no. 3, pp. 365–387, 2015.
[25] V. P. Seidel and S. O’Mahony, “Managing the repertoire:
Stories, metaphors, prototypes, and concept coherence in
product innovation,” Organ. Sci., vol. 25, no. 3, pp. 691–712,
2014.
[26] D. Rigby, “Management Tools & Trends 2013/Darrell
Rigby and Barbara Bilodeau,” Bain Co. INSIGHTS Retrieved
Httpwww Bain Compublicationsarticlesmanagement-Tools--
Trends-2013 Aspx.
[27] A. Osterwalder and Y. Pigneur, “Designing business
models and similar strategic objects: the contribution of IS,”
J. Assoc. Inf. Syst., vol. 14, no. 5, p. 237, 2013.
[28] M. Pacanowsky, “Team tools for wicked problems,”
Organ. Dyn., vol. 23, no. 3, pp. 36–51, 1995.
[29] J. C. Camillus, “Strategy as a wicked problem,” Harv.
Bus. Rev., vol. 86, no. 5, p. 98, 2008.
[30] M. Whelton and G. Ballard, “Wicked problems in project
definition,” presented at the Proceedings of the International
Group for Lean Construction 10th Annual Conference, Brazil,
2002.
[31] K. Crawford, H. Hasan, L. Warne, and H. Linger, “From
traditional knowledge management in hierarchical
organizations to a network centric paradigm for a changing
world,” Emergence Complex. Organ., vol. 11, no. 1, p. 1,
2009.
[32] M. Steen, M. Manschot, and N. De Koning, “Benefits of
co-design in service design projects,” Int. J. Des., vol. 5, no.
2, 2011.
[33] B. A. Bechky and G. A. Okhuysen, “Expecting the
unexpected? How SWAT officers and film crews handle
surprises,” Acad. Manage. J., vol. 54, no. 2, pp. 239–261,
2011.
[34] J. Hobbs and T. Fenn, “Navigating Indeterminacy
through the application of User Journeys,” presented at the
Proceedings of the 3rd International Conference on Design,
Development and Research. Kumasi, Ghana, 2013, pp. 190–
209.
[35] F. Lemke, M. Clark, and H. Wilson, “Customer
experience quality: an exploration in business and consumer
contexts using repertory grid technique,” J. Acad. Mark. Sci.,
Page 408
vol. 39, no. 6, pp. 846–869, 2011.
[36] K. Dorst, “Design problems and design paradoxes,” Des.
Issues, vol. 22, no. 3, pp. 4–17, 2006.
[37] B. Kogut and U. Zander, “Knowledge of the firm,
combinative capabilities, and the replication of technology,”
Organ. Sci., vol. 3, no. 3, pp. 383–397, 1992.
[38] H. A. Simon, “The structure of ill structured problems,”
Artif. Intell., vol. 4, no. 3–4, pp. 181–201, 1973.
[39] Lundmark LW, Nickerson, JA, Derrick, D. 2017. Wicked
Problem Formulation: Models of Cognition in the Design and
Selection of Valuable Strategies. Academy of Management
Proceedings. doi 10.5465AMBPP.2017.17551
[40] K. Lindberg and L. Walter, “Objects-in-use and
organizing in action nets: A case of an infusion pump,” J.
Manag. Inq., vol. 22, no. 2, pp. 212–227, 2013.
[41] G. A. Okhuysen and B. A. Bechky, “10 coordination in
organizations: An integrative perspective,” Acad. Manag.
Ann., vol. 3, no. 1, pp. 463–502, 2009.
[42] C.-F. Lee and M. Amjadi, “The role of materiality:
Knowing through objects in work practice,” Eur. Manag. J.,
vol. 32, no. 5, pp. 723–734, 2014.
[43] D. J. Teece, “Business models, business strategy and
innovation,” Long Range Plann., vol. 43, no. 2, pp. 172–194,
2010.
[44] F. Habermann and K. Schmidt, “The project canvas. A
visual tool to jointly understand, design, and initiate projects,”
2014.
[45] J. Kalbach, Mapping Experiences: A Complete Guide to
Creating Value Through Journeys, Blueprints, and Diagrams.
O’Reilly Media, Inc., 2016.
[46] R. K. Yin, Case study research: Design and methods. Sage
publications, 2013.
[47] A. Strategyzer, “The Business Model Canvas. Retrieved
at January 10, 2016,” 2015.
[48] P. Spieth, D. Schneckenberg, and J. E. Ricart, “Business
model innovation–state of the art and future challenges for the
field,” RD Manag., vol. 44, no. 3, pp. 237–247, 2014.
[49] M. B. Miles and A. M. Huberman, “Qualitative data
analysis: A sourcebook,” Beverly Hills Sage Publ., 1994.
[50] D. Jones and S. Gregor, “The formulation of an
information systems design theory for e-Learning,” presented
at the First International Conference on Design Science
Research in Information Systems and Technology, Claremont,
CA, 2006, pp. 356–373.
[51] S. Gregor and A. R. Hevner, “Positioning and presenting
design science research for maximum impact.,” MIS Q., vol.
37, no. 2, pp. 337–355, 2013.
[52] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S.
Chatterjee, “A design science research methodology for
information systems research,” J. Manag. Inf. Syst., vol. 24, no.
3, pp. 45–77, 2007.
[53] J. Venable, J. Pries-Heje, and R. Baskerville, “A
comprehensive framework for evaluation in design science
research,” presented at the International Conference on Design
Science Research in Information Systems, 2012, pp. 423–438.
[54] A. Osterwalder and Y. Pigneur, Business model
generation: a handbook for visionaries, game changers, and
challengers. John Wiley & Sons, 2010.
[55] S. Trimi and J. Berbegal-Mirabent, “Business model
innovation in entrepreneurship,” Int. Entrep. Manag. J., vol.
8, no. 4, pp. 449–465, 2012.
[56] C. Clark et al., “Collaboration as dialogue: Teachers and
researchers engaged in conversation and professional
development,” Am. Educ. Res. J., vol. 33, no. 1, pp. 193–231,
1996.
[57] S. Mastrogiacomo, S. Missonier, and R. Bonazzi, “Talk
before it’s too late: Reconsidering the role of conversation in
information systems project management,” J. Manag. Inf.
Syst., vol. 31, no. 1, pp. 47–78, 2014.
[58] S. Missonier, H. Avdiji, and S. Mastrogiacomo,
“APPLYING PSYCHOLINGUISTIC CONCEPTS TO IS
PROJECT MANAGEMENT TOOL DESIGN,” 2014.
[59] N. Guarino, “Formal ontology and information systems,”
presented at the Proceedings of FOIS, 1998, vol. 98, pp. 81–
97.
[60] M. Uschold and M. Gruninger, “Ontologies: Principles,
methods and applications,” Knowl. Eng. Rev., vol. 11, no. 2,
pp. 93–136, 1996.
[61] D. D. Suthers, “Towards a Systematic Study of
Representational Guidance for Collaborative Learing
Discourse,” J. Univers. Comput. Sci., vol. 7, no. 3, pp. 254–
277, 2001.
[62] A. Osterwalder, “The Business Model Ontology-a
proposition in a design science approach,” 2004.
[63] Osterwalder A., Pigneur, Y. (2002) An eBusiness Model
Ontology for Modeling eBusiness. In Bled 2002
Proceedings, AIS Electronic Library, 75-91.
[64]M. Uschold and M. King, Towards a methodology for
building ontologies. Citeseer, 1995.
[65] R. A. Burkhard, “Strategy visualization: A new research
focus in knowledge visualization and a case study,” presented
at the Proceedings of I-KNOW, 2005, vol. 5.
[66] K. Platts and K. Hua Tan, “Strategy visualisation:
knowing, understanding, and formulating,” Manag. Decis.,
vol. 42, no. 5, pp. 667–676, 2004.
[67] K. A. Piirainen, G. L. Kolfschoten, and S. Lukosch, “The
joint struggle of complex engineering: A study of the
challenges of collaborative design,” Int. J. Inf. Technol. Decis.
Mak., vol. 11, no. 6, pp. 1087–1125, 2012.
[68] A. Osterwalder and Y. Pigneur, “Designing business
models and similar strategic objects: the contribution of IS,”
Journal of AIS., vol. 14, no. 5, p. 237, 2013.
[69] F. Détienne, “Collaborative design: Managing task
interdependencies and multiple perspectives,” Interact.
Comput., vol. 18, no. 1, pp. 1–20, 2006.
[70] M. S. Kleinsmann, “Understanding collaborative design,”
2006.
[71] M. J. Eppler, “What makes an Effective Knowledge
Visualization? A Review of Seminal Concepts,” 2011.
[72] A. Comi and S. Bresciani, “Design Thinking and
Techniques in Management Teams: Understanding the Role
of Visual Facilitation,” 2017.
[73] A. Gómez-Pérez, “Evaluation of ontologies,” Int. J. Intell.
Syst., vol. 16, no. 3, pp. 391–409, 2001.
[74] R. J. Sternberg, “Implicit theories of intelligence,
creativity, and wisdom.,” J. Pers. Soc. Psychol., vol. 49, no. 3,
p. 607, 1985.
Page 409
