Microsoft Word - Final_Designing Communication Artefacts[1]Communication and information sharing are two inseparable ideas: communication is
essentially information sharing. The aim of the present study is to find improved means of
communication, collaboration and information sharing among multiple number projects
operating in Swedish municipal sector in various locations. The research employs design science
research to improve effective communication that corresponds to an ‘action research loop’
where the intervention is envisaged as introduction of IT in organization (Sein et al, 2010). Four
cycles of design and evaluation resulted in a web-based tool for communication and sharing of
information, a collaboration model (represents the collaboration among Stakeholders), a DPVC
model (documents-parts-versions-comments represents different methods of sharing documents),
a process flow model (represents the way the proposed artefact may be used by people) and a set
of design principles (rules for the development of collaboration tool). The designing of the web-
based tool, collaboration model, DPVC model, process flow model and design principles are
informed by pragmatic evaluations as well as informed arguments from the fields of knowledge
management, (multiple) project management, information systems actability theory, and open
innovation.
Keywords
Stakeholders, IT
Data- och systemvetenskap Master thesis
Supervisor: Dr. Jonas Sjöström
ERM Entity Relationship Model
HTML Hypertext Markup Language
IT Information Technology
KM Knowledge Management
LASS The act concerning assistance allowances
LSS The act concerning support and service for persons with certain disabilities
MP Multiple Projects
OI Open Innovation
List of Tables ....................................................................................................................................................
1.4 Research question(s) and Aims ........................................................................................................... 5
1.5 Disposition of the Study ...................................................................................................................... 5
CHAPTER 2: METHODOLOGICAL OVERVIEW .................................................................................... 6
2.1 Research Method ................................................................................................................................ 6
2.2 Research Approach ............................................................................................................................. 7
2.3 Research framework ........................................................................................................................... 7
2.3.1 Relevance Cycle ............................................................................................................................ 9
2.3.2 Design Cycle .................................................................................................................................. 9
2.3.3 Rigor Cycle .................................................................................................................................. 10
2.4 Design Evaluation .............................................................................................................................. 10
3.1 Actable Requirement Elicitation (ARE) .............................................................................................. 12
3.1.1 Environment ............................................................................................................................... 12
3.2 Knowledge Management (KM) ......................................................................................................... 15
3.2.1. Environment .............................................................................................................................. 15
3.3 Multiple Projects (MP) ...................................................................................................................... 19
3.3.1. Environment .............................................................................................................................. 19
3.4 Distributed Prototyping (DP) ............................................................................................................. 22
3.4.1. Environment .............................................................................................................................. 22
CHAPTER 4: DESIGN SCIENCE ARTEFACTS...................................................................................... 25
4.3 Methods ............................................................................................................................................ 35
5.1 Re-visiting the research questions .................................................................................................... 39
5.2 Conclusion ......................................................................................................................................... 40
5.3 Reflections ......................................................................................................................................... 41
5.6 Research Outlook .............................................................................................................................. 42
Appendix 1—Symbols used for designing process flow diagram ............................................................... 51
Appendix 2— Reflections and empirical data from knowledge management design iteration. ................ 52
Appendix 3— Reflections and empirical data from multiple projects Design Iteration. ............................ 57
Appendix 4—Features of Artefact ............................................................................................................... 60
Appendix 5—Symbols for Entity relationship model .................................................................................. 63
Appendix 6—Explanation of Design Principles ........................................................................................... 64
List of Figures
Figure 1: Disposition of the Study .................................................................................................. 5
Figure 2: A Three Cycle View of Design Science Research (Hevner, 2007) ................................. 8
Figure 3: Screen shot of iteration 1 of collaboration tool ............................................................. 14
Figure 4: screen shot of iteration 2 of collaboration tool .............................................................. 17
Figure 5: screen shot of iteration 3 of collaboration tool. ............................................................. 21
FifFigure 6: screen shot of iteration 4 of collaboration tool........................................................... 23
Figure 7: Collaboration Model ...................................................................................................... 27
Figure 8: DPVC model for documents sharing and discussions ................................................... 28
Figure 9: Entity relationship model .............................................................................................. 30
Figure 10: Symbols for designing process flow diagram ............................................................. 51
Figure 11: Screen shot of principle of social transparency ........................................................... 65
Figure 12: Screen shot 1 of principle of triangulated .................................................................... 66
Figure 13: Screen shot 2 for principle of triangulated for searching ............................................ 67
Figure 14: Screen shot 3 for principle of triangulated for searching ............................................ 68
Figure 15: Screen shot of principle of Stakeholder centric ........................................................... 69
Figure 16: Screen shot of principle of Information communicator pushed case .......................... 70
Figure 17: Screen shot of principle of Information communicator broadcaster case ................... 71
Figure 18: Screen shot of principle of role oriented ..................................................................... 72
Figure 19: Example screen shot 1 of principle of user supported actions .................................... 73
Figure 20: Example screen shot 2 of principle of user supported actions .................................... 74
Figure 21: Example screen shot of principle of comment recipient ............................................. 75
Figure 22: Example screen shot of principle of comment approve/disapprove ............................ 76
List of Tables
Table 1: Categories for categorizing the design iterations ............................................................ 11 Table 2: Conceptualization and description .................................................................................. 25 Table 3: Process flow model ......................................................................................................... 32 Table 4: Remarks that are used in the process flow diagram. ....................................................... 35 Table 5: Principles for designing proposed artefact ...................................................................... 36 Table 6: Reflections and data collection from knowledge management design iterations ........... 52 Table 7: Reflection and data collection from multiple projects design iterations ......................... 57 Table 8: Features of Artefact ......................................................................................................... 60 Table 9: Symbols for Entity relationships model. ......................................................................... 63
Acknowledgement
"In the name of Allah, The most Gracious, The most Compassionate".
I express sincere gratitude to my supervisor Dr. Jonas Sjöström, for his great help. His advice,
support, constructive criticism and personal interest during this research has steered me in the
right direction and helped me in completing this work.
I am also grateful to my beloved parents and friends, who are always here for me in joys, in
sorrows, in hardships and in delights. I wouldn’t have been what I am without them.
1
CHAPTER 1: INTRODUCTION
This chapter is an introduction to this thesis. Introduction to study is discussed in section 1.1.
Research problem and research context are presented in section 1.2 and 1.3. Section 1.4 contains
research question and aim of study. Finally in section 1.5, the disposition of the thesis is
presented.
1.1 Introduction
Since the 1980s, public sectors all over the world have been swept by a ‘service revolution’ in
local government and a ‘strong momentum to put customer first’ (Skelcher, 1992). This has
gained further momentum during the 1990s. As Woolridge (2002) puts it - “we are in the middle
of the most intensive program of change the public sector has ever seen”. Sirkemaa (2007)
highlights this by underlining the need for affiliation in development of e-services, particularly in
the context of public sector organizations. He suggests that collaboration is a valuable means for
achieving good results under tight budgets and limited resources. Sirkemaa starts out from a
model of stakeholders and their roles, which include government agencies, businesses,
citizens/customers/clients and the collaboration among them. The collaboration in the model can
only be achieved through knowledge acquisition and sharing (Rawas and Easterbrook, 1996). In
general a single actor doesn’t has enough knowledge required for any given project, thus it
usually requires additional information to accomplish project goals (Walz et.al. 1993). Therefore,
there is a clear need for communication and collaboration between each other. To this end of
narrowing informational knowledge gap, effective cooperation among these actors is proposed.
In this way these actors do contribute in the development of e-services. This thesis is engendered
from such a context, an attempt to highlight the benefits of stakeholders’ collaboration in e-
government development.
1.2 Research problem
A project is an attempt in which human resource; financial resources and materials are managed
in a novel way to undertake distinctive scope of work, given a finite set of resources, fixed cost
and time to achieve the goals (Turner, 1993). To achieve project goals, employees in
organizations need frequent and effective interactions. The key factor leading to the success of a
project is constant and effective communication among all project stakeholders (Verzuh, 2005).
While effective cooperation between these actors is needed so they can contribute towards the
progress of the project. The array of project stakeholders is increasingly large and diverse
(Nidiffer and Dolan, 2005). Unlike in the past, public citizens (external stakeholder) as well as
internal stakeholders, like decision makers and policy makers, often engage in project
2
management, albeit in a passive way. This underscores the need of a platform that allows such an
engagement towards a more responsive public sector management (Damian, 2007).
In an information technology (IT) intelligent project environment telecommuting is the primary
vehicle of communication which supplements and complements traditional means of information
and knowledge sharing; face-to-face meetings, filing, and telephony etcetera. Further,
organizations are progressing towards integrated digital environments where real-time
collaboration is often used to bring distributed teams closer (Nidiffer and Dolan, 2005). A real-
time collaboration platform can not only bridge soft skills gaps across dispersed units/individuals
but also enhance knowledge sharing as well as its creation (Lawrence and Lorsch, 1967;
Galbraith, 1973 and Allen, 1977 cited by Hansen 1999)1. The management of knowledge, both
its sharing and creation, is crucial for proper functioning of an organization. As Malhotra (1997)
observes – “Knowledge Management caters to the critical issues of organizational adaption,
survival and competence in the face of increasingly discontinuous environmental change.
Essentially, it embodies organizational processes that seek synergistic combination of data and
information processing capacity of information technologies and the creative and innovative
capacity of human beings”. Furthermore, knowledge is what an organization knows and thus
efficient and effective knowledge management is an important factor for organizational
performance (Liao and Wu, 2009).
The dual needs of effective multiple stakeholder engagement and knowledge generation in
project (as well as wider contexts) can hardly be the best met by conventional knowledge
sharing platforms like knowledge analysis and design support (KADS: the knowledge modeling
methodology by Schreiber et al; in 1993, Common KADS and MASK by Barthelmé et al; in
1998 etc). These methods and tools focus primarily on modeling knowledge that is embedded in
organizations while ignoring wide set of external stakeholders who are indirectly involved in
the organizational process (Irani et al, 2010). On one hand emergent knowledge, i.e. knowledge
shared through day-to-day interpersonal communication such as brainstorming sessions and
dialogues between individuals, is easily ignored in the conventional communication methods.
This means that the potential use of this kind of knowledge2 in other future projects or different
settings is usually not materialized (Hansen et al, 1999). On the other hand, a varied and wide
set of structures cannot be effectively integrated into a communication platform that relies on
face-to-face meetings, snail mails, memos etcetera.
1 The knowledge generated from intra-project communication is called informal internal knowledge (e.g. discussions, database, lesson learned etc.). This is a type of knowledge repository (James et al, 1999-2000). To transfer the knowledge from human mind (tactic knowledge) into a repository (also called explicit knowledge) organizations usually use some sort of electronic system. 2 The Knowledge generated from those projects can be categorized as knowledge of the project, Knowledge from
the project and knowledge about the project (Damm and Schindler, 2002).
3
Thus a more robust and accommodating information sharing platform holds promises to more
improved project management. Since all projects have an element of similarities across the
projects (Cooper et al, 2002), the knowledge generated from one project can be reused in other
projects and an improved platform, for example the one this essay proposes, creates
opportunities for such knowledge generation and dissemination. Such platform supports, on one
hand, effective communication and knowledge sharing among multiple projects having multiple
stakeholders, on the other promotes transparency and stakeholder inclusion.
1.3 Research Context
Sweden is a unitary state divided into 21 counties and every county has been further divided into
290 municipalities or kommuner (Eurybase 2007-08). Each municipality has a high degree of
sovereignty from the state and it is responsible for most activities at the operational level in the
public sector, like schools, infrastructure, and part of the public health care and facilitation sports
centers among others. Each municipality has a similar responsibility, as defined through
legislation. However, over the last years, there has been mainly peripheral cooperation between
the municipalities with regard to business (and IT as well) development. To address this gap, the
non-profit organization ABC was founded, with the purpose of improving collaborative business
development in Swedish municipalities.
• Knowledge management culture
• The coordinating business
• Improving public administration
1.3.1 Knowledge management culture
The first aim of ABC is to establish processes and a culture for knowledge management across
the municipalities. Knowledge management is the process of creating, capturing, acquiring and
using the knowledge to improve the performance of organization (Kinney, 1998). Among other
aspects of knowledge management, one important one is the way knowledge assets are created,
interpreted, and put into action by the members of an organization (Baird and Henderson, 2001),
e.g. knowledge created in one project is re-used in other projects. To this end a central repository
for knowledge facilitates the maintenance of shared context and improving the means for
exploration of knowledge (De Souza and Evaristo, 2004). A structure allows the ease of access;
and information retrieval contributes to this.
1.3.2 The coordinating business
“In geographically dispersed projects, coordination and communication among the players is
paramount for an efficient and effective outcome’ (Evaristo and Schudder, 2000). Little is known
about how these projects are managed or how they function. The second aim of ABC is largely
4
centered around this gap: it is to deal with multiple distributed projects in geographically distant
locations where a certain need for coordination exists, e.g. with respect to information modeling
and system architecture and collaboration with government agencies. ABC’s goal is one of
knowledge management; i.e. how coordinating efforts among distributed projects can be
enhanced, and participants can share and reuse experiences through an improved knowledge
sharing platform (this is envisaged as a repository of information from previous projects and
situations, contacts database, documents, best practices).
1.3.3 Improving public administration
The third aim of ABC is the improvement of public administration in the interest of citizens.
Citizens, in this context, play the role of both customers and tax-payers. They heading towards
the better interest of citizens includes (but not necessarily limited to) an effective, efficient and
service-oriented, as well as and an ethically informed administration (especially informed to
environmental concerns and democratic values).
The collaboration in ABC requires stakeholder-centric development strategy while improving
collaboration between municipalities. There is also an ambition to loom other stakeholder’s e.g.
citizens, government agencies, and suppliers as active project parties. There is a huge body of
evidence suggesting that the involvement of stakeholders is an important mean to change
organizations and IT systems that are amenable and form a business prospective and useful for
the needs of an organization (Sharp et al, 2006; Ehn, 1995). The introduction of new technology
(IT system) is a part of a change process and the stakeholders at early stages is more likely to
lead a solution that would be acceptable and workable for stakeholders (Kotter, 1996). In a
democratic perspective it is important to involve citizens (as external stakeholders) who are
highly engaged/largely engaged in project management. As O’Neill (2001) states: “The new
technologies will allow the citizens access to the levers of power in government. As more
information reaches the citizen, the greater the potential for them to influence and make
informed choices about governmental intentions towards masses. This potential gives a new
meaning to ‘government of the people, by the people and for the people’”. Thus, the inclusion of
stakeholders is important with respect to the capability of product-to-built, the acceptance,
complementary organizational changes and democratic values. The concept of open innovation
(Chesbrough, 2003) is scattering swiftly as a new means for innovation - this match with the
above discussion and should be further elaborated in chapter 3.
Sauer and Reich (2009) put forward that researcher should purse the idea of project as a
knowledge process. The core of a knowledge process is the idea that project performance may be
facilitated through an increased focus on learning and management. The idea of ABC is clearly
to instigate such a knowledge process while focusing on how project experiences are ‘collected’
and represented, through the game of social interaction played by the stakeholders, and how
those representations are used in other projects and operating from discrete environment. It is fair
5
to assume that IT is fit to empower such a knowledge process, spanning over multiple projects
and organizational boundaries, in parallel and over the time.
1.4 Research question(s) and Aims
To achieve the objective of this thesis author attempts to answer the following question.
• How IT artefacts can be developed to support effective communication and share
knowledge management among multiple projects operating in distributed environment
having multiple stakeholders.
The purpose of this work is to perform a research and contribute to the field of knowledge
management focusing on knowledge assets and creation for organizations using design science
research by developing an IT artefact.
1.5 Disposition of the Study
Figure 1: Disposition of the Study
Introduction chapter describes the research problem, research context and research questions.
Chapter 2 explains the research method, research approach, design oriented research approach,
Framework and tailoring of research methodology. Chapter 3 portrays the research process and
the performed design and evaluation iterations. Chapter 4 illustrates the results achieved from the
research in the form of Constructs, Models, Methods and Instantiations. Chapter 5 contains the
re-visiting of research questions and implications from research and practice.
Chapter 1. Introduction
Chapter 4. Design science artefacts
Chapter 5. Concluding discussion
CHAPTER 2: METHODOLOGICAL OVERVIEW
This chapter aims to discuss the chosen research methodology. Section 2.1 and 2.2 discuss the
research method and the research approach. Research framework is presented in section 2.3 and
section 2.4 presents the design evaluation techniques. Finally section 2.5 presents the categories
for categorizing the design.
2.1 Research Method
Research can be defined as “…. a systematic process of collecting, analyzing and interpreting
information in order to increase our understanding of the phenomenon we are interested in or
concerned of” (Leedy and Ormrod, 2005). Research is required to look at the new ideas and
making improvement in the existing ideas. Generally research has two purposes, first to make
improvement or enhancement within the existing field, secondly to improve knowledge within
oneself to understand new developments within the discipline (Gliner and Morgan, 2000 pp. 5).
The latter is one of the aims of this thesis. The only way of introducing the new dimensions in
knowledge is research and it constituent facts, figures, collected and analyzed data by different
analytical methods. Kumar (2005) defines research as “the way of thinking, critically examining
the various aspects of day to day professional work, understanding and formulating guiding
principles that govern a particular procedure, and developing and testing new theories for the
enhancement of practice”. The aim of research study is to answer the question(s) that comprise
several steps of research method and approach as well as data collection, analysis and inference.
According to Myers and Avison (2004) a research method is a strategy of enquiry underpinned
by certain underlying philosophical assumptions to research design and data collection. The
choice of research method influences the way in which the researcher collects data.
This thesis is originated in an action research project, where the author has been a part of a
municipal development project in ABC where its primary roles defined as:
1. Inquiring and actively participating in design and development of new work processes
and IT artefacts.
2. Observing, exploring and testing new design processes and outcomes.
This type of intervention is emblematic in action research projects- combining active change
with a research focused role (Susman and Evered, 1978; Davison et al, 2004). The process has
also followed a typical action research loop with diagnosis, action planning, action
taking/intervention, evaluation and specifying learning/reflection (ibid). In this research, the
author find a need for improved collaboration support within and among projects, as outlined in
the introduction. The author initiated a side-track of research that may be characterized as a
design-oriented research approach.
2.2 Research Approach
Design is a creative, problem solving process which aims to produce artefacts and to solve
organizational/human problem. According to Webster’s dictionary (1981) ‘design is to conceive
and plan out in the mind’. According to Rine’s (2002) point of view ‘design as a systematic,
directed set of decisions that are introduced, made and deployed, leading to an effective or
efficient outcome, solution, or technology.’ Miller defines ‘Design is the thought process
comprising the creation of an entity’ (internet, Design council, 2010). The idea of design is to
enhance the utility and value of artefacts. It is scientific knowledge to provide solution of
iniquitous problem encountered by human’s while interacting with external environment.
According to Danko (2005) it is a unique art and essential creative problem solving. Moreover
design explores new scenarios and discloses tactical knowledge gained through years of practical
experience.
Design science is an application (utility) of natural science (truth) and is related to applied
science. Design science has its roots in engineering where this has been used to solve practical
problems through the application of knowledge from scientific fields (Grant, 1979).According to
Simon (1969) ‘rather than producing general theoretical knowledge, design scientists produced
and applied knowledge of tasks or situations in order to create effective artefacts ’. In addition to
that design science is particularly useful in developing new technologies/products while solving
the problem at hand in creative ways (Venable, 2006). According to Hansen (1974) the aim of
design science is to recognize the laws and rules of design and its implications; this implies that
the designing process and procedure should be in systematic way (Cross, 2001) and it is also an
attempt to categorize fuzziness (Wolfgang, 2001).
Simon (1981) suggests that the primary goal of design science is ‘devising artefacts to attain
goal’ and the concern of design science then is to make the artefact useful and effective. This is
in contrast with the aims of natural science: understanding and explaining phenomena. Natural
science tries to seek truth and understand the reality and design science emphasizes on applied
science, values creation of the subjective knowledge. March and Smith (1995) spot out that
design scientists create effective artefacts by applying knowledge to tasks rather than producing
theoretical knowledge. Design science is technological and uses the knowledge available in
natural science to produce effective artefacts; on the other hand natural scientists create
knowledge which design scientists can utilize in their attempts to develop technology (Ibid). One
of the differences between natural science and design science is that natural science focuses on
seeking the truth rather than the utility that fulfills human needs. Overall, natural science is
explanatory as it aims at understanding and explaining phenomena while design science offers
treatment and creates artefacts that aim at serving human needs (Ibid).
2.3 Research framework
8
Earlier research framework in IT focused on specific research problem and studied identified
variables. Such framework was associated with several problems/weaknesses. For recognition IT
research is concerned with artificial phenomenon operating for certain purpose within an
environment and contributes in the immediate practice, also known as Action Research.
This research aims to contribute in the general practice (not limited to the actual local practices)
of e-government development or even beyond. This study results in practical knowledge of
more general-character-practical theories that are circulated in various ways (e.g. in this chapter)
and support designers in other developments and make study practical inquiry (Goldkuhl, 2007)
with dual aim of contributing in general and local practices. The concept of practical inquiry
(ibid) is based on the idea of inquiry in American pragmatism (Dewey, 1938), which is an
idealistic foundation in design science research. The term design science research is being
increasingly cited in the field of Information System (IS), however research methodology is not
clear (Niehaves, 2007; Sjöström and Ågerfalk, 2009). This thesis follows a ‘design science
research’ (Figure 2) based on Hevner et al (2004) that corresponds to the ‘action research loop’
(Susman and Evered, 1978; Sein et al, 2010), where the intervention is visualized as an
introduction of IT in organization. There are great similarities between design science research
and action research (Järvinen, 2007; Sein et al, 2010). Recently, Sein et al (2010) has proposed
‘Action design research approach’3. This approach has dual missions: adding to existing theory
and producing knowledge to support information system practitioners solving identified
problem. The idea of design as a research process is clearly acknowledged in both filaments of
research.
Figure 2: A Three Cycle View of Design Science Research (Hevner, 2007)
3 The action design research approach is a combination of action research and design research(Sein et al, 2010)
9
Hevner (2007) illustrates design science research as consisting of three interdependent cycles:
• Relevance Cycle
• Design Cycle
• Rigor Cycle
2.3.1 Relevance Cycle
The relevance cycle serves as a link between environment and design science research activities
that include building and evaluation of artefacts (March and Smith, 1995). The application
domain of relevance cycle consists of people, organizational systems, technical systems and
problems and opportunities. Good design science research project starts with identification and
presentation of opportunities and problems in real life application environment. The relevance
cycle should make sure that the design cycle originates in and contributes to the solution of some
real-world problem. The output generated from design science research should be returned to
environment for field study and evaluation in the application domain. The results of newly
constructed artefact decide whether additional iterations of the relevance cycle are needed in the
design science research project. The newly produced artefact may have deficiencies in its
functionality or inherent qualities (Performance, usability etc.) that may limit the utility of
artefact in practice. One other aspect of result from field testing of artefact is that the
requirements input to design cycle may be incorrect or the proposed artefact may be incomplete
in respect to requirements. Another iteration of relevance cycle then becomes necessary and
should be built on the feedback from the environment (field testing).
2.3.2 Design Cycle
The design cycle is one of the core cycles of design science research. This cycle iterates between
building and evaluation of artefacts. The construction of artefacts results in four types of research
outputs: Constructs Models, Methods and Instantiations. Constructs are in the form of symbol
and vocabulary. According to Schon (1993 cited in Hevner et al, 2004) it provides the language
in which problem and solution is communicated. It has significant impact on conceiving the
tasks and problems (Schon 1993: Boland 2002) and also enables the construction of models.
Model artefacts are in the form of abstractions and representations. Models use construct to
represent the real world problem and its solution space (Simon, 1996). Method artefacts are in
the form of algorithms and practices and they define process to solve the problem that can range
from formal and mathematical algorithms. Instantiations artefacts are in the form of implemented
or prototype systems and that show the working of constructs, models and methods.
Instantiations demonstrate the utility of artefact; whether an artefact is appropriate or suitable for
a given proposal.
10
Design cycle receives requirements from the relevance cycle and design and evaluation methods
are drawn from rigor cycle. The working of design cycle relies on the relevance and rigors cycle.
During the act of design science cycle, well balanced effort is required on the construction and
evaluation of emergent artefact (Hevner, 2007). To support this Iivari, (2007 cited in Hevner,
2007) states that “The essence of Information Systems as design science lies in the scientific
evaluation of artefact”. So the artefact must be tested in laboratory or experimental situation
before releasing it to the real test environment in relevance cycle.
2.3.3 Rigor Cycle
The purpose of rigor cycle provides vast knowledge to the design science research to ensure its
innovation and to make sure that design cycle is informed by theories and methods from a
relevant knowledge base and the contributions are made knowledge based. The knowledge base
contains two types of supplementary knowledge about experiences and expertise (state-of-the-art
in the application domain of research), and existing artefact and processes (meta-artefact). The
new meta-artefacts may be used to extension of original theories and methods.
This cycle provides the old knowledge to the research project to guarantee its innovation and the
researcher thoroughly research and reference the knowledge base in order to make sure that the
newly produced design is a contribution; not merely a routine design (Hevner et al, 2004). To
inline this Iivari, (2007 cited in Hevner, 2007) states “It is the rigor of constructing IT artefacts
that distinguishes Information Systems as design science from the practice of building IT
artefacts.” The rigors research depends upon the researcher’s skilled selection and application of
appropriate theories and methods for the construction and evaluation of IT artefact.
2.4 Design Evaluation
Hevner (2004) presents five design evaluation methods. First is observational. This method
involves evaluating the design as a case study (in depth study of artefact) or field study
(monitoring of artefacts in multiple projects). Second evaluation method is rather analytical. This
involves static analysis (observe structure of artefact for static qualities), architecture analysis
(study artefact into technical IS architecture), optimization (explain inherent optimal properties
of artefact) or dynamic analysis (study dynamic qualities of artefact). The third design method
consists of controlled experiment (studying artefact in controlled environment for qualities) or
simulation (execution of artefact with artificial data). The fourth design method is testing.
Testing includes functional testing (discovering failure of the system and identifying defects) or
structural testing (testing of some metric in the artefact implementation). The fifth and the final
method is rather descriptive. This employs informed argument (using knowledge base for
building convincing argument for the artefact’s utility) or scenarios (detailed scenarios of artefact
to demonstrate its utility).
Hevner (2007) illustrates design science research as consisting of three independent cycles as
discussed above. The following Table 1 is presented by considering the three view design cycle
that is used as a Research Process to answer the research question.
Table 1: Categories for categorizing the design iterations
Categories Descriptions
Environment The relevance of the design-evaluation cycle is described through a
discussion based on the intended context-of-use for the IT artefact.
Knowledge base The theoretical foundations used to inform the design are presented.
Design The design process and main features of the design product (the IT
artefact) are accounted for.
Evaluation The evaluation process and main findings from the evaluation are
presented.
additions to the knowledge base.
These three cycles are outlined in the next chapter. In order to provide some structure, a
simplified model of the three cycle view of design science research is constructed and presented
in Table 1. This also describes each and every iteration.
12
CHAPTER 3: A DESIGN-ORIENTED RESEARCH PROCESS
This chapter describes the design-oriented research process and four design and evaluation
iterations. First design iteration is presented in section 3.1. Section 3.2 and 3.3 discusses the
second and third design iteration respectively. Final and fourth design iteration is presented in
section 3.4.
3.1.1 Environment
The first iteration of design cycle was launched as a part of ‘the act concerning support and
service for persons with certain disabilities’ (LSS) and ‘the act concerning assistance allowances’
(LASS) project (described in more detail by Sjöström and Goldkuhl, 2009) where 14
municipalities were collaborating to improve public administration of personal assistance. In
their research, Sjöström and Goldkuhl concluded that there was a need for better communication
support in the project. While ABC projects try to harvest the advantages mentioned above in
chapter 1.Number of issues arise as a consequence of the distributed and inter-organizational
nature of the project work. In order to have a better understanding of these issues, face-to-face
meetings were arranged to discuss and advance the project. These meetings were arranged every
week when the project was in intense phases. Different tasks were assigned to project members
until the next meeting and the results (deliverables-in-progress, e.g. user stories. requirements
specifications, business process models, user manuals, design documentation, design prototypes,
or software) of their work were communicated to project group in order for them to prepare for
the next face-to-face meeting. When the projects reached a requirement elicitation
4and specification phase, a web based
collaboration tool was designed to support the work. This tool was useful not only to this project
but also to other ABC projects and possibly in larger context. The final stage of requirements
elicitation means that all the knowledge from previous phases need to be formulated in the form
of requirements specification for a new IT system. Now the project group faced a new challenge:
how to develop a requirements specification without requiring project staff to be brought
together at one place. Considering this the author decided to create a web site where all the
related documents and the requirements were made accessible to participating stakeholders. The
website is accessible to the project group and other invited actors. They can log into the website
in order to analyze and comment on the requirements, documents, workflow support and some
other aspects of collaboration.
4 “Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development” (Sommerville, Sawyer, Wiley sons, 1997)
13
3.1.2 Knowledge base
The knowledge base of this cycle is associated to requirements engineering 5 (RE) and support
for pursing a discussion about requirements. The existing RE model of ABC was adopted here.
The RE model of ABC allowed characterization of requirements in two aspects
1. Priority (Must-have or desired requirements)
2. Category (e.g. functional, architecture, security, or usability)
These categories were derived from another ABC project document called open technological
platform (OTP) that aims at supporting other projects with knowledge on non-functional
requirement specifications.
Moreover, the knowledge base of this cycle is also related to Information Systems Actability
Theory 6 (ISAT) which is a set of inter-related concepts for design and evaluation of IT. ISAT is
based on a social action perspective (Ågerfalk, 2003; Goldkuhl, 2007; Sjöström, 2008). It
focuses on human-to-human communication and action transparency (Sjöström and Goldkuhl,
2004; Sjöström and Goldkuhl, 2009). So there is a need of information accountability in public
sector projects. This is also an important design principle that users should see ‘who said what’
in the IT system. ISAT proposed a number of guidelines that help to design the social
interactions in IT artefacts. It provides important structure for asking important questions such as
“who uploaded documents/articles?” and “who made a comment?” Similarly, anonymous
comments are also considered important as an option to allow people to express their thoughts
and uncomfortable opinions while maintaining anonymity.
3.1.3 Design
The design process in this cycle was in deep database designing and programming. It was also
based on the experience gained from action research and theories. The design of the cycle was
discussed with other researchers and practitioners in the project and was adopted continually.
The collaboration tool at this point was a combination of requirement discussion and requirement
repository tool (The screen shot is shown in figure 3). During this iteration an emphasis was put
on the transparency in communication between project participants and intra-project
collaboration around requirements.
5 “Requirements engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” (Zave, P, 1997; Nuseibeh, Easterbrook, 2000). 6 Information systems actability theory (ISAT) is a conceptualization of information systems emphasizing their pragmatic dimensions (Goldkuhl, 2009).
14
Figure 3: Screen shot of iteration 1 of collaboration tool
3.1.4 Evaluation
The evaluation of this version of artefact was unstructured and was done with observational case
study design evaluation method (Hevner et al, 2004). In which artefact was executed with real
data. Approximately 20 people from different municipalities participated in the evaluation. All of
them were domain experts 7, i.e. practitioners working in the municipalities with different roles.
The users had their separate accounts and could log on to the system and give feedback on the
requirements for a new IT system. During the evaluation of this cycle, the general impressions
from the project participants were collected, some field notes and field reflections were made.
Furthermore, correspondence took place between researchers and practitioners to discuss the
tool. A representative from another ABC project declared that they wanted to use the tool while
discussing the tool with other researchers, it was concluded that the other project need more than
requirement elicitation features. They requested a more generic collaboration tool to discuss
documents in general.
7 A person with special knowledge or skills in a particular area; a person extremely familiar with a given group of users and their work habits (because they belong to the group) (internet, usability first,2010).
15
3.1.4 Reflections and input for future design
During the evaluation of the first cycle, the idea of first version of the tool was appreciated.
However, a more generic collaboration tool was requested. Many project participants visited the
site frequently but only few of them participated in the activity of commenting on the
requirements. The tool provided the filtering of requirement based on the project participants
roles. The roles consist of business people 8, technical specialist 9and architects
10. Business
people were asked to comment on functional requirements while architects and technical
specialists’ were asked to comment on the requirements of security. Yet only few people chose
to comment on the requirements. Now the question posed here was why they did not participate
in commenting on the requirements while discussing this issue with participants. The author got
one plausible reason that they found the requirements were complex and also they felt they were
not qualified to contribute. The other reason was that there had been a very thorough business
process analysis upfront and it was most likely that they had no comments on the requirement
because the whole group had been a part of previous activities.
The first iteration evidently indicated that this type of tool was relevant in this project and in the
context of ABC in general. Although there was a need to deal with the challenges of first
iteration and to come up with new design ideas to meet better collaboration needs.
3.2 Knowledge Management (KM)
3.2.1. Environment
On the basis of reflection taken from first iteration, the development of the tool was continued
while keeping the practical context in mind. However among many, one municipality showed
specific interest to participate in the evaluation workshop and assess the new version of the tool.
They pointed out that this type of tool (while referring to the first version of tool) was also
interesting within the municipality and thus the use of such tool should not be limited to
collaboration between municipalities. This municipality is also among the pioneers of
incorporating democratic values in business, such as action transparency in public development
and inclusion of citizens (as a stakeholder) in municipality development projects.
8 Business people: People who transact business (especially business executives) (internet, websters, 2010). 9 Technical specialists provide specialist administrative services that benefits the organization whether they are “things" or "people" related. They also lead organizations to a high level of both internal and external customer satisfaction. 10 A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies stakeholder requirements, and achieves the desired results under given constraints. This article describes the myriad responsibilities of a software architect, and attempts to identify human personality traits that naturally aid a person in such position (internet, software architect, 2010).
16
3.2.2. Knowledge base
The experiences and feedback from the first iteration suggested it to be considered as a
knowledge management problem instead of requirement engineering. Consequently the concept
of knowledge management 11 was put into use as a substitute of requirement elicitation in this
iteration. As discussed in chapter 1, a central repository for knowledge facilitates the
maintenance of a shared environment and also improves the means of investigation for
knowledge (DeSouza and Evaristo, 2004). A structure that allows ease of access and information
retrieval contributes it was considered an important aspect for the design of the collaboration
tool. For information retrieval, three different strategies were combined to facilitate:
• Top-down classification
• Bottom-up classification
Top-down classification
Top down classification is a classic approach, where information is categorized based on pre-
defined categories and also allows the classification that is agreed upon in formal discussions.
Bottom-up classification
Bottom up classification is a web 2.0 approach (O’Reilly, 2005), where the information is tagged
by capricious keywords that also allows “tag clouds” and other methods to filter and present
information.
Tracing user actions
The third strategy for information retrieval is tracing user actions. Usually the usage of IT system
leads to “technological give-offs” (Ågerfalk and Sjöström, 2007) from the user that may be used
to retrieve information and present information such as “most downloaded documents/ Articles”.
The above mentioned ‘triangulated’ strategy allows easy and flexible information retrieval and
the full utilization of these strategies provides powerful searching and filtering features in an IT
system.
11 “Knowledge management is the process of continually managing knowledge of all kinds to meet existing and emerging needs, to identify and exploit existing and acquired knowledge assets and to develop new opportunities” (Quintas, Lefrere, Jones. 1997).
17
3.2.3. Design
A second version of the collaboration tool was built, and the design of that iteration was
informed partially by ABC representatives and through discussions with the other researchers.
During this iteration the development of tool was shifted from RE into a generic document
repository and document discussion tool. This iteration tool allowed publishing and discussing
articles using an integrated Hypertext Markup Language (HTML) editor (Figure 4) that was also
an attempt to make it easier for the project participants to contribute to the contents of the
projects. Even more communication and collaboration features were introduced to motivate the
project participants to contribute more to discussion. For instance, a feature of weekly activities
report was to send all the weekly information to all project participants via emails. This version
of tool also provides the option to track “who accessed what’ (Published documents and articles).
Figure 4: screen shot of iteration 2 of collaboration tool
18
3.2.4. Evaluation
The evaluation of 2nd iteration was done using optimization technique by Hevner et al (2004),
that explains inherent optimal properties of artefact in which the system was presented and
demonstrated at designated municipality. Five representatives of the municipality having
different roles participated and gave feedback on different features of the system. The
representatives were
• Politician (Investigator)
• Project manager
13.
One prevalent argument was that many project leaders 14are not trained project managers 15. For
that they needed aid by innovative tools that help them in carrying out their project management
tasks in a well structured manner. So it was suggested that the project model of the municipality
should be integrated into the tool. It was argued in a discussion that the municipality has too little
knowledge about ongoing projects and their information. Moreover the discussion addressed the
idea of inviting external stakeholders (Citizens) to discuss the documents and articles that is a
type of ‘one click open innovation’ feature in the system. They also pointed out the need to
moderate the external stakeholders` comment in order to avoid inappropriate behavior. Apart
from these features, feedbacks were given on various aspects of the collaboration tool and user
interfaces. The empirical data collected from this iteration is included in Appendix II where it is
highlighted ‘who gave what comments on which part of system’.
12 “Project management is application of knowledge, skills, tools and techniques to project activities to achieve project requirements, Project management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring, and controlling, and closing” (James, 2007, pp.4). 13 Project coordination is planning and coordinating in administrative activities. Furthermore it helps in the development of intergovernmental and a public relations for project monitor and negotiates about agreements and also reviews and recommend projects needs. 14 Project leaders are responsible and accountable for team and also for setting up project vision and objectives. Furthermore they ensure the direction is defined and clear. 15 Project managers are responsible for to manage the project according to the set of principles and side constraint.
19
3.2.5. Reflections and inputs for future design
From the evaluation of 2nd iteration it was concluded that there was a need of managing contexts
larger than ‘in project’. Ideas and experiences from the workshop were analyzed and discussed
with other researchers and stakeholders in ABC. They underlined the need for better support of
PM support and project collaboration support. So the idea generation from workshop was
valuable for continued conceptual development of the collaboration tool, as is going to be
discussed in the next subsection.
3.3 Multiple Projects (MP)
3.3.1. Environment
In the third iteration, the environment considered was the same as in the previous iterations. The
problem was described both in the inter-and-intra municipal context of ABC, presented in the
section 3.2.
Knowledge management, project management and coordination of multiple projects are all
important theoretical foundations for collaboration model (Discussed in chapter 1). It also
became clear from the evaluation of 2nd iteration that there was a need to develop the tool in a
broader context.
The knowledge base of this iteration was conceived as project management and project
coordination. Evaristo and van Fenema (1999) propose a typology of project management where
they claim that “[the] proposed categorization of project management goes beyond the standard
categorization of single and multiple project management. It becomes clear that for each
category a whole different set of problems and potential project management techniques may be
applied”. They further propose that the potential synergies between projects were clear. A
downside was an increased need for resources to handle coordination and communication.
Furthermore Elbana (ibid) claims that ‘project scout’ is an important role in organization
operating in multiple projects within each project to avoid redundant work, sub-optimization and
to search for collaboration opportunities. The concept of project scout is similar to that of a
project coordinator in the ABC context. Although project coordinator is not necessarily a
participant in specific projects rather a somewhat permanent role in the ABC. The coordinator
need to stay informed about all the activities in the project as well as the responsibilities and
opportunities to collaborate with others. So there is clearly a need for creating value for the
project coordinator.
20
While inviting additional stakeholders to project, there is a need to address another conflict of
issues. Elbanna (2008) states that “Mechanisms for spanning and scanning the project landscape
need to be incorporated into project management practices and awareness needs to be increased
that an information systems project is no longer a local matter that can be treated as a closed
innovation isolated from the rest of the organization. It should be noted that the inclusion of
partnerships and alliances in the project does not always mean collaboration, but could bring
rivalry that needs to be recognized and accounted for”. According to the author’s point of view
this is not an argument to keep stakeholders out of the development process although this may
bring complexity. Postponing problems for later on essentially reduces the feasibility of any
project. While on the divergent, there is huge evidence that conflicts should be addressed as early
as possible (A number of reasons for this were listed in the chapter 1).
3.3.3. Design
In this iteration, a lot of refined model of roles in the municipal development process were
implemented in the system, e.g. different views of project news, articles, documents and version
handling of the documents and articles. Furthermore the concepts for project coordination and
follow-up were implemented, based on flexible project model template (defined by ABC). A
feature to control the visibility of documents, articles (figure 4) and news empowers were also
implemented. In this iteration the tool also provided the facility to invite different stakeholders to
review and discuss project artefacts.
21
Figure 5: screen shot of iteration 3 of collaboration tool.
Furthermore a new feature of live search for documents and articles was introduced in this
iteration.
3.3.4. Evaluation
In this iteration, a system was presented at a seminar at Linkoping University to six business-
oriented researchers interested in “use qualities of the information system”; the researchers had
advanced technical skills and adequate awareness of other similar systems and thus were in a
position to evaluate this system. Simulation technique (execution of artefact with artificial data)
was used in this iteration (Hevner et al, 2004). One of the scenarios was document sharing
(Shown in figure 5) and discussing. Among the six researchers, two considered adapting the tool.
They considered using the tool in an ongoing action research project to discuss a design
prototype for a municipal e-service. To this end they needed some convenient way of exposing
their design prototype to get feedback on it. The prototype was demonstrated with artificial data,
22
which triggered discussions based on the actual needs in the project. An existing prototype, that
needed to be discussed in that project group, was discussed, and it was argued that ‘our’
prototype needed to be developed in a manner to make it possible to discuss ‘their’ prototype
using ‘our’ prototype. During demonstration they figured out that ‘our prototype’ does not
completely suit their needs. This was because ‘our system’ only provided the facility to discuss
the documents as a whole rather than in parts. So they pointed out the need of discussing
documents in parts as well. One argument was that if the document is big and contains more
pages then it is difficult to specify the relation of received comments to the part of document.
They also suggested that the tool should be in Swedish language for this particular project. The
empirical data collected from this iteration is included in Appendix III.
3.2.5. Reflections and inputs for future design
The feedback generated from the seminar was discussed and analyzed by considering the current
design of tool and two important conclusions were reached:
a) It was felt that there was a need to structure big documents in the tool.
b) The language of the system tool needed to be changed from English to Swedish. This
would encourage participants whose first language is Swedish to contribute more in terms
of feedback.
Thus, the idea generation that took place in seminar was valuable for continued conceptual
development, as discussed in the next subsection.
3.4 Distributed Prototyping (DP)
3.4.1. Environment
In the fourth iteration, the environment was a bit different from the previous three iterations. In
this iteration the problem was described to researcher community who were the part of these
municipalities and aiming to improving the business in municipalities and bridging the gap
between stakeholders and governments.
3.4.2. Knowledge base
The experiences and feedback from the third iteration indicated that there was a need for
structuring information. According to Lokuge et al (1996) structured information is easily
understandable as compared to scattered information or sliced information (Andrews and
Heidegger, 1998). They further explained that information structuring means an arrangement of
pieces of information and that arrangement might be 1-D ordering, 2-D array or information
nodes with connecting association links. The visualization of that information is important while
retrieving the information there are two main ways of retrieving the on-line information,
querying and browsing (Salton, 1989). Querying technique retrieves the information on given
23
parameters while browsing assumes that information has been already organized in hierarchical
structure, table of contents or in hyperlinks. Browsing technique was used in this iteration for
information visualization and easy accessing of related documents / articles because users want
to know which document / article belongs to which category.
3.4.3. Design
In this iteration, a lot of features were refined and incorporated e.g. communication action issues,
navigation issues, use of design space, layout issues and feedback messages. Furthermore a new
feature, slicing the information and presenting information in hierarchal structure to increase the
visualization of documents, was incorporated (figure 5).
FifFigure 6: screen shot of iteration 4 of collaboration tool .
3.4.4. Evaluation
The evaluation of this iteration was done using simulation technique in which the artefact was
executed with artificial data (Hevner et al, 2004. The artefact was demonstrated to the researcher
24
(the one who was interested in using this system), with artificial data in the system (figure 6).
One positive feedback was that the hierarchical structure looked great and it was easy to access
documents and navigates among them. During system development the author posed a lot of
questions to researcher that inspired the researcher to further investigate the document
decomposition feature (in practice and theory); the “ideal” trait of the tool. This is the
emblematic situation in system development where a lot of details are needed to implement
technical solutions such as database design.
3.4.5. Reflections and inputs for future design
After four design and evaluation cycles, we had an ideal design at that point which amalgamated
views and experiences from the four iterations.
25
CHAPTER 4: DESIGN SCIENCE ARTEFACTS
This chapter aims to provide important insights into the outcomes of design science research.
Design science research results in four types of artefacts: Constructs, Models, Methods and
Instantiations (March and Smith 1995, Hevner et al. 2004). To date, four iterations of design
cycle have been completed. The results of these iterations are presented below.
4.1 Constructs
Constructs constitute the ‘language’ to specify problems and their solutions (Robert 2008).
Construct artefacts are in the form of symbol and vocabulary (March and Smith, 1995).
According to Schon (1993, cited in Hevner et al 2004), constructs provide the language in which
problem and solution are communicated. It has significant impact on conceiving the tasks and
problems (Schon 1993, Bolan 2002) and also enables the construction of model.
The constructs developed in this research are in the form of conceptualization that was used to
describe the problems and its solutions within the domain (March and Smith, 1995).
Conceptualization defined the terms that were used in describing and thinking about the tasks.
Table 2 contains the conceptualization and its description developed in this research.
Table 2: Conceptualization and description
Conceptualization Description
“who uploaded documents/articles?” and “who made a
comment?”
Tag clouds Tag clouds are used to filter and present the tagged
information (e.g. tagging by capricious keywords).
Technological give-offs Usage of IT system leads to “technological give-offs” from
the user that may be used to retrieve information and
present information such as “most downloaded documents/
Articles”.
Open innovation Invites external stakeholders (e.g. Citizens) to discuss the
documents and articles. Furthermore they have access to
bulk of projects.
26
displaying those in a way so that readers could easily
identify the relation among them (e.g. hierarchal
structuring in the form of table of contents).
Knowledge management A central repository for knowledge facilitates the
maintenance of a shared environment and also improves
the means of investigation for knowledge
Project management, project
concepts for project coordination and follow-up were
implemented, based on flexible project model template
(defined by ABC).
4.2 Models
Models use constructs to represent problems and their solutions (Robert 2008; Simon 1996).
Model artefacts are in the form of abstractions and representations (March and Smith, 1995). The
three models, which were developed from this research, are:
1. Collaboration Model
3. Entity Relationship Model
4. Process Flow Model
4.2.1Collaboration Model
The collaboration model developed is shown in the figure 9, where a number of stakeholders
with major influence e.g. senior management, project coordinators, project managers, project
members and external stakeholders (such as citizens or representatives of companies or the
media) were included. It should be noted that organizational belongings were not explicitly
concerned here: everyone would belong to any organization (or none). The model only
represents the collaboration of people, not who they are or why they are in the project. Therefore,
the model should be understood in the light of existing stakeholders’ management strategy.
27
Figure 7: Collaboration Model (Originally published by Sjöström. J & Iqbal. I at SWEG 2010)
In the above figure, the author has represented the abstracted ‘core communication needs’ for
each stakeholder.
Project coordinators contribute to project management by designing project models, initiating
projects, setting up vision and goals and assigning project leaders. They are always aware of the
status of a project and take part in the project news, documents and articles that are directed
towards them. Project coordinators are expected to report back to the top management, thus they
need an executive view of project activity with the option to look into it in more detail.
4.2.1.2 Project Leaders
Project leaders are able to update information about the project, change the project status and
assign a deputy project leader. Further, as an ordinary project participant, they may add project
news, documents, and articles (or new versions of documents and articles). While doing so, they
can target certain audiences who have access. For instance, project leaders may choose to make a
document “public” which immediately makes the document available to citizens and other
external stakeholders for reading and discussing. Project members could also be assigned the role
of moderator; which would enable them to moderate the received comments. Further, project
leaders are supported in their roles by a collaboration tool that is based on the model which
supports actions and the way they communicate.
28
4.2.1.3 Project Members
Project members are able to access project news, documents and articles that are directed
towards them, and discuss those artefacts with others. They can also get involved by adding
news, documents and articles and control the target groups in the same way as the project
leaders. The idea was to improve the document management and collaboration between the
project members in distributed projects.
4.2.1.3 Citizens and other external stakeholders
Citizens and other external stakeholders have a point to access to a large number of projects;
with the possibility to search for documents, articles, news and discuss them with other
stakeholders. This way citizen and other external stakeholders get involved in the discussion and
will be made aware of ongoing projects.
4.2.2 DPVC Model
The Document, Parts, Versions and Comments (DPVC) model developed is shown in Figure 8.
It represents the different types of relations between different types of documents along with
document discussion. The documents can be shared, improved and discussed as a single
document or can be broken down into several smaller documents before they are shared. It
should be noted that the intent here was to show the relations among documents, their parts,
versions and comments, not their types and the ways to share them. Thus the model needs to be
understood as document sharing, improving, discussing and dividing the document into smaller
parts.
29
4.2.2.1 Information sharing
The available information in the form of articles, files and images etc. can be shared between the
project coordinators, project leaders, project members and external stakeholders mentioned in the
collaboration model. In addition to that, the documents can be further divided into small parts
and improved while creating versions of the documents. These smaller documents can also be
discussed among the actors.
4.2.2.2Depth in information
The shared information can be divided into smaller parts Pi {P1, P2…. Pn}, and these smaller
parts can be further divided into smaller parts and can be improved while creating versions of
each smaller part. The division of small parts depends upon the actors, how much depth they
want to create while dividing the document into parts. Each part of documents can also be
discussed among the actors.
4.2.2.3Improving information
The shared information can be improved while creating the versions Vi {V1, V2……Vn} of
each document and its parts. Versions can also be improved while creating the versions of
version. Along with documents and their parts, the versions can also be discussed among a
number of actors mentioned in the collaboration model.
4.2.2.4 Discussing information
All the shared information (files, articles, and images etc), their parts and versions can be
discussed among the actors. These actors can discuss the information while giving feedback or
comments Ci {C1, C2….. Cn} on the documents, their parts and versions. The feedback
messages are composed of textual descriptions which help improving the shared documents.
4.2.3 Entity Relationship Model (ERM)
Entity Relationship Model (ERM) developed in this research is shown in Figure 9 (Chen, 1976).
It is a set of constructs and a data modeling formalization. The representation of information
system’s data in the form of entity relationship is more appropriately termed as a model (March,
Smith, 1995). The entity relationship diagram was developed to facilitate the database design by
allowing the designer to express the logical properties of the database in an enterprise schema.
The word enterprise means the organization for which the database is kept. The items in the
figure represent ‘things’ in the real-world, and the relationships between the real-world ‘things’
are expressed by relationships in the model. Figure 9 describes the environment in terms of
30
model.
Figure 9: Entity relationship model
16 The term entity means any object that exists and can be distinguished from other objects. It is a person, place, event, object or concept in the real world that we wish to represent in the database. 17 The attributes of an entity set define the properties or qualities of the entity type. 18 Relationships are connections or interactions between the entity instances.
31
4.2.4 Process Flow Model (PFM)
The process flow diagram is shown in the Table 3, which shows the way the IT artefact may be
used by the people. Messages are transferred to artefacts by different actors or the other way
around. These actions can be communicative, consequential and automatic actions. A
communicative action is one in which actors can perform actions through and by support of the
system. Consequential actions are those which all the users can perform in reaction to retrieved
messages from the artefact. Automatic actions are system performed tasks in response to actor
input (Goldkuhl and Ågerfalk, 2002). Appendix 1 shows the symbol and the descriptions of the
symbol that are used while designing the process flow diagram.
The four columns in Table 3 capture the flow of information, actors, actions and remarks. The
first column shows the flow of information, the second shows the involvement of actors in
different steps and the third shows the type of actions preformed by actors on certain steps while
the fourth contains remarks about why these steps are important.
32
33
Top management, project
leaders, Deputy project
Info
communicative
communicative
automatic
Moderator
From
D
34
35
Remarks
Table 4 shows the remarks and description of the steps used in the process flow diagram.
Table 4: Remarks that are used in the process flow diagram.
Remarks Descriptions
Remark 1 Only authorized user has the access of sharing (Articles, files, and images etc) and
retrieving the required information,
Remark 2 Shared information is validated against the set of defined rules before storing in
the system.
Remark 3 Shared information is filtered or retrieved according to rules. (e.g., project leaders,
project members and citizens etc.)
Remark 4 External stakeholders’ (such as citizens) comments are only visible, once they are
approved by the project moderators.
Remark 5 To keep track of all the activities going on in a certain time period.
Remark 6 Email notifications of all the previous activities can be sent to everyone.
4.3 Methods
Methods describe processes which provide guidance on how to solve problems. Method artefacts
are in the form of algorithms and practices and they define the process to solve the problems that
can range from formal and mathematical algorithms. They can provide guidance on how to solve
the problem e.g. through textual description and best practices or some combinations. (Hevner et
al, 2004)
The methods in this research are in the form of textual description and design principles that
were used as a guideline to solve the identified problems.
4.3.1 Textual description
The designed system contains a number of features and modules (included in Appendix 4).
Considering current research, the way information is shared and communicated among project
participants are two vital features.
First, information in the system is shared in terms of projects that include objectives and
information of the project. Information of project includes project phases, status, news, and
project members. Each project can have different type of articles, documents, image files and
video files. The articles in the system can be written in Wikipedia-style and HTML-editing with
36
the possibility of editing them later on. Documents can be uploaded as doc, docx, ppt, pptx, and
pdf etc up to 10MB size. Same rule applies for image and video files. Articles/documents/files
are shared by authorized users of the system: articles, documents or files could be improved by
creating versions. Furthermore, information can be shared in the form of feedback generated
from the shared articles/documents/files.
Second, communication of shared information that is done with the help of Really Simple
Syndication (RSS), Weekly activity report, comments and tagging users. RSS feeds are used to
notify all project members about the events (uploads, comments, project status changes). Project
leaders communicate all the previous happened events to the participants of projects with the
help of a ‘weekly activity report’. The sharing of information in the form of documents/articles is
categorized according to the pre-defined categories and tagged using arbitrary keywords (top-
down and bottom-up tagging). The project participants can start the discussion while making
comments on the uploaded documents, files and written articles.
4.3.2 Design principles
Table 5 demonstrates the design principles that were drawn from the design as research process
(Chapter 3).
Principles Origins Justifications Examples
should see who said what in the IT system.
Information Systems Actability Theory
Section 3.1.2 Figure 11
flexible information retrieval and full
utilization of this strategy provide powerful
searching and filtering features in an IT system.
knowledge
management,
Information
retrieval
feedback, a type of ‘one click open innovation’
feature in the system. And providing them a
point of access to retrieve information.
Open Innovation Section 3.2.4 Figure 15
Principle of Information communicator
Actable
Requirement
availability of information is broadcasted to
everyone (e.g. activity report). Furthermore it
also allows you to stay informed by displaying
the latest information.
views and features for different roles in the IT
system. For instance, a view screen for the
coordinator is specifically suited to provide
him/her with an overview of all the activities in
the project.
leads the user to navigate between different
screens within the system automatically to
complete a single action. e.g. ‘Save project and
add phases’ feature allow users to save project
information and navigate them to project phase
screen.
project
management,
Information
Systems
Actability
Theory
allowed to provide their feedbacks on shared
information.
Information
Systems
Actability
before displaying it to other stakeholders.
Information
Systems
Actability
Apart from above mentioned design principles, the proposed artefact also inherits the usability
principles presented by Nielsen (1993).
38
Instantiations are problem-specific. It operationalizes constructs, models, and methods (March
and Smith, 1995). Instantiations demonstrate the utility of artefact whether it is suitable to the
given or not.
Instantiation artefacts are in the form of final working system or solution of the identified
problem. An instantiation in this research is in the form of web-based tool that can be accessed
through web pages using web browsers, such as Google Chrome, Mozilla, Firefox and Microsoft
Internet Explorer etc. These web pages are methods for distributing information to a widely
distributed user base.
A web-based tool has been designed to assist in sharing information among multiple
stakeholders in multiple projects operating from various locations. The use of the tool is based on
assumptions (e.g. user profiles) created by project leader or deputy project leaders of the project.
The project participants could either have a single or multiple roles in multiple projects. The
roles include project member, project coordinator and project moderator etc. These roles are
responsible for performing different types of actions in the tool.
After designing and assigning of project roles to the participants, one could identify the assigned
project roles and given privileges in the assigned projects by logging onto the tool. According to
the assigned roles, participants can retrieve and share information (e.g. Article, Files, and Images
etc) from and into the system. Sharing and retrieving of information in the resultant artefact is
done using the following ways.
1. A master program, written in Server side language PHP, can be used to code a fixed type
of information sharing. These information sharing can be executed through system calls
or subroutines.
2. A master program, written in script language such as JavaScript and Ajax can be used to
code or retrieve the information from the artefact.
3. Graphic methods are used to link the sequence of process and to provide user more
flexibility to navigate in the artefact.
The resultant artefact presented here is designed using theoretical concepts from the field of
‘knowledge management’ (e.g. files, article, and images etc), ‘project management’ (e.g. project
management model and information of multiple projects), ‘open innovations’ (e.g. sharing of
information among external stakeholders like citizens) and pragmatic experiences collected from
each design iteration.
CHAPTER 5: CONCLUDING DISCUSSION
This chapter comprises of the answers to the research question (Section 5.1). Section 5.2
describes the conclusion and section 5.3 contains the researcher’s reflections on this research.
Further implication for practice and research are presented in section 5.4 and 5.5.
5.1 Re-visiting the research questions
The purpose of this work was to develop an IT application that meets the collaboration needs
within ABC projects. Through four iterations of design and evaluation, the identification of
collaboration needs in this context has been developed as project coordination, project
management, intra and inter-project collaboration and open innovation in multiple stakeholders’
context. This is partial answer of the research question:
• How IT artefacts can be developed to support effective communication and share
knowledge management among multiple projects operating in distributed environment
having multiple stakeholders
The question has been further explored in chapter 3, where the adopted procedure of designing
artefact were presented, beginning from requirements engineering (section 3.1.2) and augmented
by knowledge management (section 3.2.2), project management (section 3.3.2), open innovations
(section 3.2.4), and distributed prototyping (section 3.4.2).
At the beginning of this research the purpose of designing a tool was to collect requirements
from distributed project participants. An emphasis was put on the transparency in
communication between project participants and intra-project collaboration around the
requirements collected. Later experiences and empirical data collected from the first iteration
indicated the problem as a challenge of knowledge management rather than just requirement
elicitation. So the theoretical knowledge management concepts were applied and a generic
centralized repository was developed. Furthermore, the collected experiences and discussion lead
to the inclusion of external stakeholders (a kind of open innovation) for the discussion of shared
information. The empirical data and feedback generated from the evaluation of knowledge
management iteration required project management features in the tool. Therefore the designing
of tool in this iter