designing communication artefacts
TRANSCRIPT
Designing Communication Artefacts
Imran Iqbal
Abstract
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
Open innovation, Multiple project management, knowledge Management, collaboration,
Stakeholders, IT
Uppsala Universitet Institutionen för informatik och media
Data- och systemvetenskap Master thesis
Supervisor: Dr. Jonas Sjöström
Abbreviations
ARE Actable Requirement Elicitation
DP Distributed Prototyping
DPVC Document- Parts- Versions- Comments
ERM Entity Relationship Model
HTML Hypertext Markup Language
IS Information System
ISAT Information Systems Actability Theory
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
OTP Open Technological Platform
PFM Process Flow Model
PM Project Management
RE Requirements Engineering
RSS Really Simple Syndication
Table of Contents List of Figures...................................................................................................................................................
List of Tables ....................................................................................................................................................
CHAPTER 1: INTRODUCTION ................................................................................................................. 1
1.1 Introduction ......................................................................................................................................... 1
1.2 Research problem ............................................................................................................................... 1
1.3 Research Context ................................................................................................................................ 3
1.3.1 Knowledge management culture ................................................................................................. 3
1.3.2 The coordinating business ............................................................................................................ 3
1.3.3 Improving public administration .................................................................................................. 4
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
2.5 Characterizing a design iteration....................................................................................................... 11
CHAPTER 3: A DESIGN-ORIENTED RESEARCH PROCESS .............................................................. 12
3.1 Actable Requirement Elicitation (ARE) .............................................................................................. 12
3.1.1 Environment ............................................................................................................................... 12
3.1.2 Knowledge base ......................................................................................................................... 13
3.1.3 Design ......................................................................................................................................... 13
3.1.4 Evaluation ................................................................................................................................... 14
3.1.4 Reflections and input for future design ..................................................................................... 15
3.2 Knowledge Management (KM) ......................................................................................................... 15
3.2.1. Environment .............................................................................................................................. 15
3.2.2. Knowledge base ........................................................................................................................ 16
3.2.3. Design ........................................................................................................................................ 17
3.2.4. Evaluation .................................................................................................................................. 18
3.2.5. Reflections and inputs for future design ................................................................................... 19
3.3 Multiple Projects (MP) ...................................................................................................................... 19
3.3.1. Environment .............................................................................................................................. 19
3.3.2. Knowledge base ........................................................................................................................ 19
3.3.3. Design ........................................................................................................................................ 20
3.3.4. Evaluation .................................................................................................................................. 21
3.2.5. Reflections and inputs for future design ................................................................................... 22
3.4 Distributed Prototyping (DP) ............................................................................................................. 22
3.4.1. Environment .............................................................................................................................. 22
3.4.2. Knowledge base ........................................................................................................................ 22
3.4.3. Design ........................................................................................................................................ 23
3.4.4. Evaluation .................................................................................................................................. 23
3.4.5. Reflections and inputs for future design ................................................................................... 24
CHAPTER 4: DESIGN SCIENCE ARTEFACTS...................................................................................... 25
4.1 Constructs .......................................................................................................................................... 25
4.2 Models ............................................................................................................................................... 26
4.2.1Collaboration Model ................................................................................................................... 26
4.2.2 DPVC Model .............................................................................................................................. 28
4.2.3 Entity Relationship Model (ERM) ............................................................................................... 29
4.2.4 Process Flow Model (PFM) ......................................................................................................... 31
4.3 Methods ............................................................................................................................................ 35
4.3.1 Textual description ..................................................................................................................... 35
4.3.2 Design principles ........................................................................................................................ 36
4.4 Instantiations ..................................................................................................................................... 38
CHAPTER 5: CONCLUDING DISCUSSION ........................................................................................... 39
5.1 Re-visiting the research questions .................................................................................................... 39
5.2 Conclusion ......................................................................................................................................... 40
5.3 Reflections ......................................................................................................................................... 41
5.4 Implications for Practice .................................................................................................................... 41
5.5 Implications for Research .................................................................................................................. 41
5.6 Research Outlook .............................................................................................................................. 42
REFERENCES ............................................................................................................................................ 43
Electronic Reference: .............................................................................................................................. 50
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.
Besides other things, ABC aims at
• 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 2. Research Methodology
Chapter 3. Design as research process
Chapter 4. Design science artefacts
Chapter 5. Concluding discussion
6
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.
7
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).
11
2.5 Characterizing a design iteration
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.
Reflections and input
for future design
Consequences for continued design are proposed, along with potential
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 Actable Requirement Elicitation (ARE)
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 engineering5 (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
Theory6 (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 experts7, 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 people8, 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 management11 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
• Tracing user actions
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
• Two process developers (IT security coordinator, Controller)
• Politician (Investigator)
• Project manager
• Webmaster
• Two researchers
The representatives requested new modules: project management12and project coordination
13.
One prevalent argument was that many project leaders 14are not trained project managers15. 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.
3.3.2. Knowledge base
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
Social transparency Transparency in communication between projects such as
“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.
Managing big documents/articles Slicing the big documents/articles into smaller parts and
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
coordination
Refined model of roles in the municipal development
process were implemented in the system. Furthermore the
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
2. Documents - Parts – Versions - Comments (DPVC) 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.
4.2.1.1 Project Coordinators
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.
Figure 8: DPVC model for documents sharing and discussions
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
entities16, attributes17, and relationships18. Appendix contains the symbols for entity relationships
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
Table 3: Process flow model
33
No info for user
Cont
C
User
request for
infor
System check
user roleNot Exist
Process request
and retrieve the
required info
Check for
vulgarity
Exist
Wrong Info
Process and make
available for users
Information retrieval and discussion Actors
Top management, project
leaders, Deputy project
leader, project
coordinator, project
member, Citizens
Actions Remarks
communicative
automatic
automatic
Top management, project
leaders, Deputy project
leader, project
coordinator, project
member, Citizens
automatic
Correct Info
User input
their feeback
communicative
automatic
automatic
Remark 3
Remark 4
From
B
Displayed the info
Process and save
feedback
Discard the wrong
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).
Table 5: Principles for designing proposed artefact
Principles Origins Justifications Examples
Principle of social transparency: People
should see who said what in the IT system.
Information Systems Actability Theory
Section 3.1.2 Figure 11
Principle of triangulated: Allows easy and
flexible information retrieval and full
utilization of this strategy provide powerful
searching and filtering features in an IT system.
knowledge
management,
Information
retrieval
Section 3.2.2 Figure 12,
13,14
Principle of stakeholder centric: Inviting
stakeholders for discussion and providing
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
(Pushed or broad caster): Information is
Actable
Requirement
Section 3.1 Figure 16,
17
37
pushed in the system by different users and
availability of information is broadcasted to
everyone (e.g. activity report). Furthermore it
also allows you to stay informed by displaying
the latest information.
Elicitation,
knowledge
management
Principle of role oriented: Allows different
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.
project
management
Section 3.3.2 Figure 18
Principle of user supported actions: System
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
Section 3.3.2 Figure 19,
20
Principle of comment recipient: Users are
allowed to provide their feedbacks on shared
information.
Information
Systems
Actability
Theory, Open
Innovation
Section 3.2.4 Figure 21
Principle of comment approval/disapproval:
The received comments from external
stakeholders can be approved / disapproved
before displaying it to other stakeholders.
Information
Systems
Actability
Theory, Open
Innovation
Section 3.2.4 Figure 22
Apart from above mentioned design principles, the proposed artefact also inherits the usability
principles presented by Nielsen (1993).
38
4.4 Instantiations
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.
39
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 iteration includes theoretical concept from project management and the project
model from ABC. Pragmatic evaluation of tool in third iteration highlighted the needs for slicing
large information into smaller parts while maintaining the relations between smaller parts as well
as with the main part. So the concept of ‘parent-child’ relation was applied here to fulfill the
required need. Furthermore, the ‘parent-child’ relation assisted designer in easy navigation
among smaller parts under single umbrella of the main part. The concept of ‘parent-child’
relation provides the opportunity of discussing the information in depth.
40
5.2 Conclusion
The present research aims to improve effective communication and information sharing among
multiple stakeholders in multiple projects operating from dispersed locations. Another important
aspect of this research is to provide a platform to stakeholders to discuss and share information
among each other as well as with participants who are coordinating business. This research was
conducted in ABC context, which has an active agenda in improving public administration,
coordinating businesses and introducing knowledge management culture among the Swedish
municipalities.
To improve the cooperation among these municipalities the author designed a web-based tool
that helps the municipalities to securely share and discuss the information among them. For the
purpose of developing the web-based tool, author decided to employ the design science research
methodology. Design science research comprises of three cyclic views; relevance cycle, design
cycle, and rigor cycle (Hevner et al, 2007). Among these cycles, design cycle is the most
important cycle which contains the activity of designing and evaluating the artefacts. The
relevance cycle provides the real-world environment where the actual artefacts are to be
operated. The rigor cycle supports the design cycle while providing theoretical knowledge of the
related problem that is to be addressed.
Design science research results in the form of Constructs, Models, Methods, and Instantiations
(March and Smith 1995, Hevner et al. 2004; Robert 2008). A web-based tool (Instantiations) was
developed to improve effective communication and information sharing. The development of
web-based tool was based on four design and evaluation iterations and includes pragmatic
experiences and theoretical concepts of requirement elicitation, knowledge management,
information system actability theory, project management, open innovation and information
browsing. Development of the tool relied on the constructs; vocabulary used in each design
iteration and process flow diagram describing the way people communicate with designed tool,
Methods; set of design principles and Textual description and Models; collaboration model,
documents–parts–versions-comments model and entity relationship model presented in chapter
4. The pragmatic evaluation of the tool was done using different evaluation techniques (e.g.
observational, optimization, simulation etc.) presented by Hevner et al (2004), with a diverse set
of stakeholders (business process developers, investigators, webmasters, researchers, project
managers, stakeholders etc.). Thoughts and reflections collected from every single design
iteration were incorporated in the design iteration which followed. Design science is recognized
as a valid research strategy to produce solid deliverables.
The design principles and proposed models: Collaboration model and DPVC model sprung from
practices in Knowledge Management (KM), Open Innovation (OI), Information System
Actability Theory (ISAT) and multiple project management in distributed environment. The
41
models and design principles incorporate a number of important aspects that are considered
relevant in practice.
5.3 Reflections
One suggestion to similar other designers who would like to design application using design
science research is to keep the design as simple as possible so that post evaluation changes are
kept to a minimum. Simplicity of design encourages trial users to provide feedback and
eventually to use the final product. Another important aspect while doing design science research
project is the collection and management of empirical data from each design iteration and
applying that data into next design iteration. The author finds that these are important issues so
one should be careful when designing new iteration while keeping previous design in mind.
5.4 Implications for Practice
The IT application will be published under an open source license and thus will be available to
use for everyone. It supports basic but dynamic project management support so that it can meet
the needs of as many organizations and stakeholders as possible. According to action research
and pragmatism, the IT system should be tested in actual use so that in-depth experiences may be
collected. It is hoped that the new version of the system will be put in use in several projects in
the context of ABC, in order to facilitate more evaluations and further investigate the value of
this tool- the DPVC and the collaboration models, design principles and to bring this research
into practice.
5.5 Implications for Research
Implication of research is addressed here using the concept of theories of ‘social translucence’ by
Erickson et al (2002). He highlights three important building blocks for effective communication
and collaboration (Suh et al, 2008). First, making socially significant information visible and
salient, the proposed pragmatic view of design clearly embraces the value of significant
information visible and salient. Second, supporting awareness of the rules and constraints
governing the system is supported by the users’ roles and constraints used in the design of
application. Third, accountability of actions (Goldkuhl. 2003; Heritage, 1984; Aakhus, 2004) is
in line with the core features of system that is ‘who said what’ in the system. Furthermore, Suh et
al (2008) highlights the needs of richer social context and improved measurements for readers
and editors. These concepts were also aligned to the pragmatic view of design where it is
allowed ‘how much’ and ‘what’ information and with ‘whom’ they want to share. Moreover the
concepts of improved measurements were also associated here while presenting information such
as “most downloaded documents/ Articles”. Furthermore, Shneiderman (2000) mentions
disclosing patterns of past performance and providing rich feedback to the users for the sake of
42
increasing trust in online systems and meaningful data could provide meaningful history to the
users and facilitate them to judge the trustworthiness of other users (Resnick, 2000). The
previous performance and meaningful history were provided to users using ‘weekly activity
report’ feature in the proposed pragmatic view of design.
5.6 Research Outlook
This work left a number of abstractions problem types and principles which may be refined and
presented in a more useful format. Future research may focus on the following points.
• Improving the design of the tool according to external stakeholders (Citizens) needs: a
responsive design should aim to capture the most diverse feedback from both internal and
external stakeholders. The tool developed in this research focused only on the needs of
internal stakeholders.
• This thesis focused on the major functions and implementation features of the web-based
tool, which left a lot of uncovered arguments, related to user interface related studies. The
usability of the tool could be researched with user trail.
• The design-oriented research process followed here may be further refined in relation to
‘Action Design Research’ (Sein et al, 2010).
43
REFERENCES
Aakhus M., (2004) Felicity conditions and genre: Linking act and conversation in LAP style
conversation analysis, in proc of the 9th Intl Conference on the Language Action
Perspective (LAP2004), Rutgers University.
Ågerfalk P., Sjöström J., (2007). Sowing the Seeds of Self- A Socio-Pragmatic Penetration of the
Web Artefact. In Proceedings of the 2nd International Conference on the pragmatic Web
(PragWeb’2007), October 22-23, Tilburg, The Netherlands
Ågerfalk, P., (2003). Information Systems Actability: Understanding Information Technology as
a Tool for Business Action and Communication. Doctoral Dissertation. Department of
Computer and Information Science, Linköping University, 2003, Printed in Sweden by
UniTryck, ISBN: 91-7373-628-7.
Amer Al-Rawas and Steve Easter Brook., (1996). Communication problems in Requirements
Engineering: A Field Study: Proceedings of the First Westminster Conference on
Professional Awareness in Software Engineering, Royal Society, and London.
Andrews K. and Heidegger H., (1998)., Information slices: Visualizing and exploring large
hierarchies using cascading, semi-circular discs. In IEEE Information 1998, Late
Breaking Hot Topics Procs., pages 9–12, Raleigh Durham, NC.
Baird, L., & Henderson, J. C., (2001). The Knowledge engine: how to create fast cycles of
knowledge-to-performance and performance-to-knowledge (1st ed.). San Francisco:
Berret-Koehler Publishers.
Barthelmé, F. Ermine, J.L Rosenthal-Sabroux, C. (1998) An architecture for knowledge
evolution in organisations, European Journal of Operational Research, 109, pp. 414-427
Bashar Nuseibeh, Steve Easterbrook., (2000). Requirements engineering: a roadmap,
Proceedings of the Conference on The Future of Software Engineering, pp. 35-46,
Limerick, Ireland
Boland, R. J., (2002). "Design in the Punctuation of Management Action" in Managing as
Designing: Creating a Vocabulary for Management Education and Research, R. Boland
(ed.), Frontiers of Management Workshop, Weatherhead School of Management
(available at http://design.cwru.edu)
Chen, P. (1976). The Entity-Relationship Model: Toward a Unified View, ACM Transactions on
Database Systems 1(1), pp. 9-36.
44
Chesbrough, H., (2003). Open Innovation: The New Imperative for Creating and Profiting from
Technology. Boston: Harvard Business School Press.
Cooper, K. G., Lyneis, J. M., and Bryant, B. J., (2002). “Learning to learn, from past to future,”
It’ll. Project Management, Elsevier, vol. 20, no.3, pp. 213-219.
Cross, N., (2001). ‘Designerly ways of knowing: design discipline versus design science’,
Design Issues, vol. 17, no. 3, pp. 49-55, Available from: http://oro.open.ac.uk/3281/
(accessed 31/10/08).
Curtis, B., Krasner, H., & Iscoe, N. (1988). A Field Study of the Software Design Process for
Large Systems. Communications of the ACM, 31(11), pp. 1268-1287
Damm, D. and Schindler, M., (2002), Security issues of a knowledge medium for distributed
project work. Intern. J. of Project Management.
Daniela Damian, (2007). Stakeholders in Global Requirements Engineering: Lessons Learned
from Practice (Vol. 24 no. 2) pp. 21-27.
Danko, S., (2005). Design as a tool for Leadership and Social Change, Cornell University,
Department of Design and Environment, New York.
Davison, R. M., Martinsons, M. G. & Kock, N., (2004). Principles of canonical action research,
Information Systems Journal, Vol. 14, pp. 65-86.
DeSouza , K. C. and Evaristo, J. R., (2004). Managing Knowledge in Distributed Projects.
Communications of the ACM, Vol. 47, No. 4, pp. 87-91.
Dewey, J., (1938). Logic: The theory of inquiry, Henry Holt, New York. Ehn, P., (1995). Informatics: Design for Usability. In the Infological Equation: Essays in Honor
of Börje Langefors, (B. Dahlbom, Ed.) Gothenburg, Sweden: Gothenburg studies in
information systems, Gothenburg University, pp. 159-174.
Erickson, T. & Kellogg, W. A. (2000). Social translucence: an approach to designing systems
that support social processes. In ACM TOCHI, 7, 59-83.
Elbanna, A., (2008). Open Innovation and the Erosion of the Traditional Information Systems
Project Boundaries, in IFIP International Federation for Information Processing, Volume
287, Open IT-Based Innovation: Moving Toward Cooperative IT Transfer and
Knowledge Diffusion, eds. Leon, Bernardos, A., Casar, J., and DeGross, J. (Boston:
45
Springer), pp. 423-439.
Evaristo, R. and van Fenema, P. C., (1999). A Typology of Project Management: Emergence and
evolution of new forms. International Journal of Project Management, Vol. 17, No. 5, pp.
275-281.
Evaristo, R., Schudder R., (2000). Geographically Distributed Project Teams: A Dimensional
Analysis. Proceedings of the 33rd Hawaii international conference on system sciences. Gliner, J. A., & Morgan, G. A., (2000). Research methods in applied settings. Mahwah, NJ:
Lawrence Erlbaum.
Goldkuhl, G., (2003). Conversational Analysis as a theoretical Foundation for Language Action
Approaches? In proceedings of the 8th International Working conference on the
Language-Action Perspective on Communication Modelling, pp. 51-69, Tillburg, The
Netherlands, July 2003.
Goldkuhl, G., (2007). What does it mean to serve the citizen in e-services? Towards a practical
theory founded in socio-instrumental pragmatism. International Journal of Public
Information Systems, Vol. 2007 (3), pp. 135-159.
Goldkuhl, G., (2009). Pragmatic Qualities of Information Systems – Actability Criteria for
Design and Evaluation. Proceedings to 11th International Conference on Informatics and
Semiotics in Organisations (ICISO), Beijing, China.
Grant, D., (1979). Design methodology and design methods, Design Methods and Theories,
vol.13, no. 1.
Hansen, F., (1974). Konstruktionswissenschaft, Carl Hanser, Munich.
Hansen, M. T., Nohria, N., and Tierney, T., (1999). “What’s your strategy for managing
knowledge?” Harvard Business Rev., Vol. 77, no, 2, pp. 106-116.
Heritage, J., (1984). Garfinkel & Ethnomethodology. Polity.
Hevner, A. R., (2007). A Three Cycle View of Design Science Research. Scandinavian Journal
of Information Systems, Vol. 19 (2), pp. 87-92.
Hevner, A.R., March, S.T., Park, J., and Ram, S., (2004). Design Science in Information Systems
Research, MIS Quarterly, vol. 28 (1), pp. 75-105.
46
Ian, Sommerville, and Pete Sawyer, (1997), Requirements engineering a good practice guide, 1st ed. Published by; John Wiley & Sons, Inc. NY, USA, ISBN: 0471974447. pp. 404.
Iivari, J., (2007). A paradigmatic analysis of information systems as a design
science, Scandinavian Journal of IS 19 (2), pp. 39–64. Irani, Z., Weerakkody, V., El-Haddadeh, R., Ghoneim, A., Lee, H., (2010). A collaborative
Decision Support Platform for Best Practice Exploitation in the Public Sector (COOPERATE): A Research Note. tGov Workshop’ 10(tGOV10), Brunel University, West London, UB8 3PH.
James P. Lewis, (2007). Fundamental of project management, 3rd ed. Published by American
management association printed in the United States of America ISBN.10: 0-8144-0879-
6, ISBN.13: 978-0-8144-0879-7, pp. 4
James, W. Cortada, John A. Woods, (1999-2000). The knowledge management year book. pp.
18–27.
Järvinen, P., (2007). Action Research is Similar to Design Science. Quality & Quantity, Vol. 41,
Springer, pp. 37-54.
Kinney, T., (1998). Knowledge management, intellectual capital and adult learning. Adult
Learning, 10(2), pp. 2-5.
Kotter, J., (1996). Leading Change. Boston: Harvard Business School Press.
Kumar, R., (2005). Research Methodology: A Step-by-step Guide for Beginners, 2nd Edition,
SAGE.
Leedy, P.D., and Ormrod, J.E., (2005). Practical Research. 8th ed. Pearson Education, Inc., USA,
ISBN : 0131247204.
Liao, S., Wu. C., (2009). The relationship among Knowledge management, organizational,
Learning, and organizational performance. International journal of business and
management vol. 4. No. 4
Lokuge, I., Gilbert, S. A., & Richards, W., (1996). Structuring information with mental models:
A tour of Boston. Proceedings of CHI '96 , ACM Press.
Malhotra., (1997). Knowledge Management, Knowledge Organizations & Knowledge Workers:
A View from the Front Lines (Published in Maeil Business Newspaper of February 19,
1998).
March, S. T., & Smith, G. F., (1995). ‘Design and natural science research on information
47
technology’, Decision Support Systems, no. 15, pp. 251-266.
Myers, M. D., and Avison, D. E., (2004). Qualitative Research in Information System. 2nd ed.
London: SAGE publications.
Nielsen, J., (1993). Usability Engineering, Academic Press, Boston, MA.
Nidiffer, K. E., Dolan, D., (2005). Evolving distributed project management: IEEE journals.
Niehaves, B., (2007). On Epistemological Pluralism in Design Science. Scandinavian Journal of
Information Systems. (19:2), pp. 93-104.
O’Neill, R.J. Jr., (2001). The Levers of Power, In 21st Century Governance, supplement to
Government Technology.
O’Reilly, T., (2005). What is Web 2.0: Design Patterns and Business Models for the Next
Generation of Software, available on-line from
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.
Project Management Inst. A guide to the project Management body of knowledge, 3rd Ed. 2004.
Quintas, P., Lefrere, P., Jones, G., (1997). "Knowledge management: a strategic agenda", Long
Range Planning, Vol. 30. pp. 385-91.
Rine, D., (2002). Lectures in Patterns-Directed Design, George Mason University.
Robert Winter (2008). “Design science research in Europe” European Journal of Information
Systems, pp. 470–475.
Salton, G., (1989). Automatic Text Processing; The Transformation, Analysis, and Retrieval of
information by Computers. Addison Wesley, Reading, MA.
Sauer, C., and Reich, B.H., (2009). Rethinking IT Project management: Evidence of a new
mindset and its implications. International Journal of Project Management, Vol. 27, pp.
182-193.
Schreiber, G., Wielinga, B., and Breuker, J. (1993). KADS: A Principled Approach to
Knowledge-Based System Development, Academic Press, London, UK.
Schon, D.A., (1993). The Reflective Practitioner: How Professionals Think in Action, Basic
Books, New York.
48
Sein, M., Henfridsson, O., Purao, S., Rossi, M., and Lindgren, R. (2010). Action design research
MIS Quartely.
Sharp, H., rogers, Y. Preece, J., (2006). Interaction Design: Beyond Human-Computer
Interaction, 2nd Edition.
Shneiderman, B., (2000). "Designing trust into online experiences", Comm. ACM, 43(12), ACM
Press (2000), 57-59.
Simon, H. A., (1969). The sciences of the artificial, MIT Press, Cambridge Mass.
Simon, H. A., (1981). The sciences of the artificial, MIT Press, Cambridge Mass.
Simon, H., 1996. The Sciences of the Artificial, 3rd Edition, MIT Press, Cambridge, MA.,
ISBN:0-2626-9191-4.
Sirkemaa, S., (2007). Implementating information technology in the learning process. In
Proceedings of the 6th WSEAS International Conference on E-activities, pp. 261-265.
Susman, G. I., & Evered, R. D., (1978). An assessment of the scientific merits of action research.
Administrative Science Quarterly, vol. 23 (4) pp. 582-603.
Sjöström, J., & Goldkuhl, G., (2004). The semiotics of user interfaces: A socio-pragmatic
perspective. In virtual, Distributed and Flexible Organizations: Studies in Organizational
Semiotics (pp. 217-236). Netherlands: Springer.
Sjöström, J., (2008). Making Sense of the IT Artefact – A Socio- Pragmatic Inquiry into IS Use
Qualities. Linköpings Universitet. Licentiate Thesis.
Sjöström, J. and Iqbal, I., (2010). "An Emerging Collaboration Model for e-Government
Projects". In Proceedings of the 7th Scandinavian Workshop on e-Government (SWEG
2010),Örebro, Sweden, January 2010.
Sjöström, J., and Ågerfalk, P. J., (2009). An Analytic Framework for Design-oriented Research
Concepts. In Proceedings of the Fifteenth Americas Conference on Information Systems,
San Franciso, California.
Sjöström, J., and Goldkuhl, G., (2009) Socio-instrumental Pragmatism in Action. In Whitworth,
B., De Moor, A. (Eds, 2009) Handbook of Research on Socio-Technical Design and
Social Networking Systems, IGI, Hershey.
49
Skelcher, C., (1992). Managing for Service Quality, Longman, Harlow.
Suh, B., E.H.Chi., A.Kittur., and B.A Pendleton., (2008) “Lifting the veil: Improving
accountability and social transparency in Wikipedia with WikiDashboard,” In
proceedings of 26th Annual ACM conference on Human Factors in Computing System,
pp. 1037-1040.
Morten T. Hansen, (1999). The Search-Transfer Problem: The Role of Weak Ties in Sharing
Knowledge across Organization Subunits Journal; Administrative Science Quarterly, Vol.
44
Resnick, P., Zeckhauser, R., Friedman, E. and Kiwabara, K. (2000) “Reputation systems”
Comm. ACM, 43(12), ACM Press (2000), 45–48.
Turner, J. R., The Handbook of Project-Based Management. McGraw Hill, Maidenhead, 1993.
Venable, J., (2006). ‘The role of theory and theorizing in design science research, First
International Conference on Design Science Research in Information Systems and
Technology.
http://ncl.cgu.edu/designconference/DESRIST%202006%20Proceedings/2A_1.pdf.
Verzuh, Eric. (2005). The Fast Forward MBA in Project Management, Second Edition.
Hoboken, NJ: John Wiley & Sons.
Walz, D., Elam, J. and Curtis, B., (1993). Inside a software design team: Knowledge acquisition,
sharing, and integration. Communications of the ACM 36(10), pp. 63-77.
Webster’s Third New International Dictionary, Merriam-Webster Inc., Springfield,
Massachusetts, US, 1981, pp. 611.
Wolfgang, J., (2001). ‘A scenario for design’, Design Issues MIT, vol. 17, no. 2, pp. 64-80.
Woolridge, E., (2002). “Modern times”, People Management, Vol. 8 No.7, pp. 28-30.
Zave, P., (1997). Classification of Research Efforts in Requirements Engineering. ACM
Computing Surveys, 29(4): pp. 315-321.
50
Electronic Reference:
Design Council.
1. www.hku.hk/bse/interdisciplinary/what_is_design.pdf , (last accessed 17-02-2010)
Eurybase. The Information Database on Education Systems in Europe (2007-2008)
1. http://eacea.ec.europa.eu/education/eurydice/documents/eurybase/eurybase_full_reports/SE
_EN.pdf, (last accessed 19-08-2010).
Software architect.
1. http://www.softwarearchitectures.com/go/Discipline/Introduction/ArchitectsResponsibilities/ta
bid/59/Default.aspx, (last accessed 29-10-2010).
Usability first.
1. http://www.usabilityfirst.com/glossary/domain-expert/ , (last accessed 20-10-2010).
Webster’s.
1. http://www.websters-online-dictionary.org/definitions/Businesspeople?cx=partner-pub-
0939450753529744:v0qd01-tdlq&cof=FORID:9&ie=UTF-8&q=Businesspeople&sa=Search#922 ,
(last accessed 29-10-2010).
51
Appendix 1—Symbols used for designing process flow diagram
The following diagram describes the symbols used in designing process flow diagram.
Figure 10: Symbols for designing process flow diagram
52
Appendix 2— Reflections and empirical data from knowledge
management design iteration.
This appendix includes the data and reflections collected during the demonstration of system.
one Municipal archiver (A) , one investigator/politician (B), IT security coordinator (C),
Controller ; Business process mapper (D), one Web site administrator (E), and two researchers
were participated(R).
Table 6: Reflections and data collection from knowledge management design iterations
# Actor Comment from
actor
Interpretation / design consequences Category
1 C Is it possible to
choose whether you
get a notification or
not?
Communication
Design
2 C Only PDF files?
Other files like JPG,
Wav, Doc et cetera?
General design
3 C What happens if I
forget my password?
Do I have to contact
an administrator?
Feature needed: Send email with
password to registered user who forgot
password. User has to provide their
email adress.
Communication
Design
4 C Search keyword
only, or also title,
filename et cetera?
Search Design
5 D This system is also
interesting for other
people than ABC
Reflection: Can be used in thesis
discussion? When is the design
applicable/useful?
6 E Comparable to
”ABC project place”,
but in the ABC
project place there
are lots of messages
and you can’t see
Positive response to the current design,
where it is visible what has been added
to the site.
Communication
Design
53
what happened
7 E My first intuitive
feeling is that it
looks very good.
General Design
8 C There should be info
about the project
leader, project
members et cetera.
Metadata about the
project.
Project
Management
System wanted
9 A Living system Reflection: This system doesn’t appear
problematic from an archiving
perspective. See also #20, #21?
Archiving
functionality
10 D Hard for
organization to know
what projects we
have. We need to see
what projects are
running.
Design idea: The system should
support multiple projects. Project table
needed. Connection between users and
their roles in different projects. More
consequences?
Project
Management
System wanted
11 A, D There should be a
hierarchical structure
/ graphical image
showing the status of
all the projects
P1 75%
P2 20%
P3 15%
..Or based on the project model in the
municipality.
Note that this concerns communication
from project leaders to management /
project coordination / other
stakeholders
Project
Managament
System wanted
12 C FC (FirstClass) can
do many of these
thinkgs, but it is
structured in a
General Design
54
strange way. FC is
an early bulletin
board system still in
use in many
municipalities.
13 E How about a
notification
circle/square
notifying the user.
Design idea: RSS feeds as an optional
way of communication what is going
on in the site.
Communication
Design
14 D Each report’s status
in our project model
should be visible
Project
Management
System wanted
15 C People want to be at
one place
Design thought: Possibly, ”Samplats
II” can be placed in a proxy portlet in
Sitevision – the CMS system used for
the ABC web site and Sandviken
kommun’s web site.
General Design
16 E FC has all these
features, but it is
messy.
Communication
Design/ General
Design?
17 A Is it possible to view
the file structure
(folders and files)
where the documents
are stored?
This data cannot be viewed as a single
hierarchical structure.
General Design?
18 … Long discussion
about search options
There needs to be a powerful way of
searching information. At the moment,
three different strategies to enable
searching are present in the system’s
design:
• Top down (posts relate to predefined categories)
• Bottom-up (users ”tag” posts) • User actions are recorded (e.g.
downloads)
Search Design
55
There is a need to harness the
possibilities by the three strategies in
use.
There is a need for a flexible, powerful
search interface as well as predefined
reports (which are not known at the
moment)
19 R Why wouldn’t you
use this system?
… The IT department
might have
objections, such as:
• It hasn’t been used earlier
• Is it secure? • ”Yet another
system”
Reflection: These ”counterforces”
appear to be valid for Sandviken, but
not for ABC
Politics
20 E When we have the
final document,
should it be sent to
our document
system? When does
it have to be
uploaded to the
document system?
(Long discussion with no clear
answer)
Project
Management
System wanted
21 D Who is the owner of
the document?
Project
Management
System wanted
22 A There needs to be a
project owner.
(Long discussion)
Design idea: The system could support
project members with different roles
Project
Management
System wanted
56
(e.g. project owner) in the
administrative workflow. Make people
aware of their obligations. E.g: The
first page could inform the project
leader that a finalized document has
been uploaded, and that it needs to be
put into the document system and/or
archive. The project leader can mark
the document as processed (when done
with it), and it will disappear from the
”to-do list”.
23 D Who initiates a
project, and what is
the assignment?
Reflection: If the development goes in
the direction of a project management
system, there is a need to study PM
literature to ensure that this issue, and
other PM issues, as well supported by
the system.
Note: It is not only about project
management within a project, it is
about the coordination and control
over all projects in the municipality.
Project
Management
System wanted
24 R What about
public/citizen
comments on
documents?
Another type of communication:
Project group communication with
citizens using the system.
Open innovation
25 E Moderation may be
needed to prevent
spam and abuse
Design thought: The first page after
login should include comments from
citizens that need to be approved (or
disapproved)
Open innovation
26 A This is in line with
our vision on a
citizen-centered
municipality
Open innovation
57
Appendix 3— Reflections and empirical data from multiple projects
Design Iteration.
This appendix includes the data and reflections collected during the demonstration of system in
second iteration. Column 1 contains the number of comments, column 2 contains the comments,
column 3 contains the interpretation/ design consequences and column 4 contains the category.
Table 7: Reflection and data collection from multiple projects design iterations
# Comments Interpretation / design consequences Category
1 Latest
document
and child
should also
include child
documents
”Latest documents” and ”latest articles” should also
include child documents that have been uploaded/changed
(i.e. the way it used to be before the latest changes) –
people are supposed to be able to see activity here
Communication
design
2 Show latest
comments as
well
Previously, we have also discussed a ”latest comments”
feature in the tool showing user comments with links to the
document/article it concerns.
Communication
design
3 Two
separate link
for
approving
and
disapproving
comments
When ”approving” a public comment, the interface is
confusing
� Selecting”discard” and then clicking”approve” is a confusing design. There should rather be two distinct buttons: ”Approve comment” and ”Disapprove comment”.
� When a comment has been approved/disapproved, it should no longer be in the list (a decision has been made, don’t bother the user anymore). Otherwise, what happens when there are 500 public comments in the system?
Communication
design
4 News should
be presented
nicely
The news could be nicer formatted, e.g
Headline
This is the news text.
By ABC, 2010-04-17.
Communication
design
58
5 Links to go
and add
comments or
view
comments
on each
document
When viewing a document, there should be
� links (before the image) to scroll down on the page to ”view comments” (Visa kommentarer) and ”add comment” (Kommentera) – we must make sure that the users find these features
� A link to go back to the ”overview” (Översikt), i.e. the hierarchical structure this document belongs to
Navigation
design
6 Latest
Parent
document
should also
be in
separate
category
Perhaps there should be a headline named ”Dokumentträd”
in the left menu, showing all the ”root” documents
(Designprototyp and test in the current situation) –
somehow, the user needs easy access to ’browse’ the
document structure
Navigation
design
7 Image can
be seen as
large
When showing a document that is an image, it’s probably
good if you can click the image to see it fully (just like you
can click the file name – my intuitive reaction was to try to
click the image)
Navigation
design
8 Remove
extra spaces
A lot of space is unused (e.g. in the top of the screen / title,
which is more than 150px high)
Design space
9 Width of
page is big
Content page could be wider (only 520px now) Design space
10 Preserve
same size of
image while
displaying
When stretching images: Preserve width-height ratio – right
now, some of the images are stretched strangely (e.g. 1.3)
� Alternatively or in addition: Make it possible to also put articles in the content hierarchy
Design space
11 There
should be
one link of
edit
information
per page
The hierarchy view is great, but the indentations are a bit
strange (maybe the ’edit information’ should be moved to
the page where you view the document?
Design Layout
59
12 Remove the
“::” from all
pages
What’s the point with the double colons (”::”) everywhere? Design Layout
13 Align text to
left
A lot of stuff is still ’centered’ that should look better
justified to the left.
Design Layout
14 Special
Swedish
character
encode
strangely
Something strange happened in the character encoding; å ä
ö doesn’t show properly in the user interface.
Design Layout
15 Change text
in Swedish
language
There’s is still a lot of English mixed with the Swedish Design Layout
16 Feedback
messages
should be
visible
Feedback messages, e.g. when adding a comment to a
document, should be put so that it is clearly visible when
the page has been reloaded. In the current design, you
sometimes need to scroll down to see the feedback
message.
General Design
60
Appendix 4—Features of Artefact
This appendix shows the feature of developed artefact.
Table 8: Features of Artefact 1 Create user(s)
2. Create new project, fill in objectives et cetera, assign project leader (existing user).
3. Monitor list of projects, including project phase and status (%, expected finish date).
4. Terminate and/or hibernate project (hibernation --> read-only – nothing new can be added).
5. Edit project info (public and internal view).
6. Add project news (public and internal view).
7. Assign user as project member.
8. See existing users when creating new users (alpha order)
9. Assign user as deputy project manager. A project can have only one deputy project
manager.
10. Assign user as public comment moderator. A project can have several moderators.
11. Set project status (phase, %) and comment project status. All comments & changes are
stored and accessible for project co-ordinator).
12. Project co-ordinators, (deputy and ordinary) project leaders, and project members must
login in order to access the system.
13. In case user forgets his password, for that system should provide the facility of getting their
username and password through email.
14. Single user can be member / Project leader/ Deputy Project leader of number of projects.
15. User can select a single project from number of available projects, for the purpose of
viewing details.
16. Once user has selected the certain project from the list of available projects then it is
necessary that design should display the login-in project, project role and current login-in
user.
17. User can change his/her password.
61
18. User can hide/unhide the project news.
19. User can update the project and project phase status.
20. Project leader/Deputy project coordinator can approve/ disapprove the membership of the
project members.
21. Create categories for document/ articles.
22. Create conferences
23. Write articles (Wikipedia-style, HTML-editing).
24. Edit information of articles (Wikipedia-style, HTML-editing).
25. Upload documents (various file types).
26. Edit information of uploaded documents (various file types).
27. Articles and documents can be broken down into parts. e.g. one big document can have N
parts (Parent-child relationship).
28. Viewing screen displaying which part of document and article belongs to which document
and article.
29. Version handling of documents and articles and also for their parts.
30. Comment articles and documents and their parts as well.
31. While viewing document/ article, there should be a link to scroll down on the page to”view
comments” (Visa kommentarer) and”add comment” (Kommentera).
32. See who did what (e.g. uploaded, downloaded a document, wrote a comment, is responsible
for actions et cetera).
33. RSS support to notify all project members about the events (uploads, comments, project
status changes)
34. Weekly activity report (including all events during the last week) sent to the project
members.
35. View of previous weekly report that has been sent to the project members.
36. All uploads are clarified according to the pre-defined (project co-ordinator) categories,
AND tagged using arbitrary keywords (top-down and bottom-up tagging).
62
37. Any uploaded article or document may be selected to be "public", i.e. open for citizens
(anyone) to view and comment.
38. See latest articles, documents, and comments (after login).
39. See latest child articles, documents and their comments.
40. Search articles, documents, and comments.
41. Design should provide hints to the user while searching the documents and articles.
42. Advanced search of articles, documents and comments on the basis of categories and
projects.
43. See which articles/documents/comments, he/she already watched or downloaded - Search
for unwatched articles/downloads/comments.
44. See public info about ongoing projects
45. See project news after login.
46. See public documents/articles and comments on them. Comments must be approved by
moderator, to avoid foul language, rudeness, unethical (or illegal) behavior, and pranks.
Comments that await approval will have the comment text replaced with”<Awaiting
approval>”.Comments that have been approved will be fully shown, and the
text”<Approved by (actor who approved comment)>” appended in the end. Comments that
have been disapproved will have comment text replaced with”<Disapproved by (actor who
disapproved comment)>”. -- It is important that there is a transparency in approval process,
in order to win and keep the trust among citizens.
47. Approve public comment for publishing (moderator)
63
Appendix 5—Symbols for Entity relationship model
Table 2 contains the symbol that are used in designing entity relationship model and description
of those symbols
Table 9: Symbols for Entity relationships model.
Symbol Descriptions
Optional one
Mandatory one
Optional many
Mandatory many
64
Appendix 6—Explanation of Design Principles
This appendix shows the screenshots and brief description and demonstrating the principles.
These design screenshots are taken from the final version of the system. Few of the screen shots
contain real-world data. In those cases information is crossed in order to avoid secrecy.
65
Figure 11: Screen shot of principle of social transparency
Figure 13 contains the main menu, left menu which contains active project information, recent
article, files, and user feedback which in this case is ‘Add Comments’. Futhermore screen
illustrates who said what in the system that is visible in each given feedback e.g. under
‘Dokumentinformation’ the date and time and author name has shown who shared the document,
that is same in the ‘Comments by’ section.
66
Figure 12: Screen shot 1 of principle of triangulated
Principle of triangulated tagging is shown in Figure 14 where project coordinators are allowed to
tag the users at the predefined categories based on project roles. Screen shot 14 contains the
‘News title’, ‘Detail’, and ‘Visibility’. The visibility section contains the predefined roles that
exists in the system e.g. project leader, project coordinator etc. The users are allowed to select
the user roles to display this project news.
67
Figure 13: Screen shot 2 for principle of triangulated for searching
Figure 14 describes the searching of files for all the active users of the selected projects. ‘Visa
dokument’ section contains the ‘File Name’ that allows user to enter the name of file to be
searched.
68
Figure 14: Screen shot 3 for principle of triangulated for searching
A screen shot 16 describes another way of searching articles from the system based on the
projects. ‘Article Search’ section contains ‘Project Name’ and ‘Article Name’. The users are
allowed to select project from the available projects (e.g. project name) in the system and can
enter the name of article (e.g. Article name) to be searched.
69
Figure 15: Screen shot of principle of Stakeholder centric
This screen shot supports external stakeholders (e.g. citizens) to provide their feedback on the
shared articles, files and project news that are diverted towards them. ‘Föräldertest’ contains the
‘date and time’, ‘username’, and the details of the shared article. The external stakeholders (e.g.
citizens) are allowed to provide the feedback or to discuss the shared article with other
stakeholders by providing merely names.
70
Figure 16: Screen shot of principle of Information communicator pushed case
This screen allows the user to share/push the information into the IT artefact based on the
predefined criteria. Furthermore this screen includes the information of document related to
conference, type and topics included in the document. This screen helps user to push/insert
information of the document and itself. These documents could be broadcasted later.
71
Figure 17: Screen shot of principle of Information communicator broadcaster case
This screen supports project leaders or project coordinators to broadcast the available
information in the IT system. They are supported with the functionality of selecting information
during certain time period. In addition to that they are supported with their actions while
providing previous broadcasted information (e.g. from ‘which’ date to ‘which’ they broadcasted
the last information and ‘when’ and ‘who’ had done).
72
Figure 18: Screen shot of principle of role oriented
Figure 20 illustrates that users are supported by their predefined roles. Different screens are
available for different type of user’ roles e.g. project leader, coordinator, moderator, and project
members etc. ‘Artikel träd’, ’Senaste artiklar’, ’Dokumentträd’, and ’Senaste dokument’
contrains the information of articles and documents that are diverted to project members.
73
Figure 19: Example screen shot 1 of principle of user supported actions
This screen shows that users are supported in their actions e.g. users can fill the information of
project and then screen support them with the ‘action of further completing the task’ which in
this case is ‘save project and add phases’. Once the user filled in the information ‘Project Name’
and ‘Project Details’ and press the button ’Save project and add phases’ the screen redirects the
user to new screen (Figure 22) that contains ‘Project Phase Name’ and ‘Project Phase
Description’. The system assists users to perform different actions.
74
Figure 20: Example screen shot 2 of principle of user supported actions
75
Figure 21: Example screen shot of principle of comment recipient
This screen supports ‘active’ users of the project to give their feedback on the shared article. The
users need to login into the system before performing any action. Users are allowed to provide
feedback on any shared information. Furthermore the previously received feedback messages are
also displayed in reverse order to provide user with the information ‘who’ said ‘what’ about
‘what’ in the artefact.
76
Figure 22: Example screen shot of principle of comment approve/disapprove
This screen supports the ‘project moderator’ to approve/disapprove the comments received from
external stakeholders (Citizens). The approved comments are available for both internal and
external stakeholders.