ENABLING OR DISABLING WITH OLD SPECIFICATIONS
A New Information System Based on Old Specifications
Raija Halonen
Department of Information Processing Science, University of Oulu, P.O.Box 3000, FIN-90014 University of Oulu, Finland
Keywords: Information system, Specifications.
Abstract: This research concentrates on the development of an information system that was based on previously made
specifications. We study the influence of before-made specifications and discuss the difficulties in adopting
them. In our case we had several universities involved in the development project and the aim was to
implement a joint information system to be used by student affairs officials and students in universities.
Implementing information systems by several organisations is highly dependent on collaboration between
the organisations. We discuss how the collaboration was managed in our case and show what the role of
previous specifications was. We conclude that despite the specifications, the information system was
finalised.
1 INTRODUCTION
Implementing information systems has been
described in several studies. Our aim is to analyse
the importance of specifications when a new
information system (IS) is implemented in the
context of several organisations participating in the
development project. Our research concentrates on
the importance of specifications and the influence of
them in a case when the specifications were made in
a previous project by other owners and participants.
Our research shows that even if the specifications
were evaluated to be perfect enough, their influence
was not only positive on the development of the new
IS project.
The research material is gathered from an IS
project where an interorganisational IS was
implemented in the context of several universities
participating in the project. The aim of the project
was to pilot an IS in order to support the
management of student mobility between
universities. Universities represent a special
environment (Hearn, 2004). Hearn continues that
academic organisations have their own cultural and
national context, where science is practiced,
organised and managed in specific, nationally-based
institutions, with specific cultural and national
characteristics.
The biggest user group consisted of students who
wanted to perform studies in other universities as a
part of their academic degrees. However, the main
user group consisted of student affairs officials who
managed the student mobility, supporting or
rejecting rights to study.
We have chosen action research and related
methods in our study relying on Baskerville and
Wood-Harper (1988) when they evaluate that action
research is ideal for studying information systems in
practice.
Collaboration is always needed when there are
people involved in one project (Barki and Hartwick,
2001; DeChurch and Marks, 2001) but our research
shows that the importance of collaboration is not
only needed but sometimes even fundamental. When
developing an interorganisational IS the role of
collaboration even increases.
2 DEVELOPING INFORMATION
SYSTEMS
IS as a concept has many descriptions and meanings.
In this paper it is discussed a wholeness that consists
of database, users, data collection device, data
sharing devices, interpretation of information,
organisational structures and processes. Lyytinen
and Lehtinen (1987) see that the information
systems development is both a political and a
symbolic process.
483
Halonen R. (2006).
ENABLING OR DISABLING WITH OLD SPECIFICATIONS - A New Information System Based on Old Specifications.
In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 483-488
DOI: 10.5220/0002491404830488
Copyright
c
SciTePress
The literature recognises research about
implementing information systems in distributed
organisations (e.g. Munkvold, 1999; Kotlarsky and
Oshri, 2005) but there is not much literature about IS
acquisitions made by several users representing
different organisations.
Interorganisational information systems differ
from an internal or distributed IS by allowing
information to be sent across organisational borders
(Johnston & Vitale 1988). Johnston and Vitale have
studied user participation and they note that in
intraorganisational systems involving users slows
the design but pays back during implementation.
Further, involving a cross-section of company
employees helps developing new ideas and builds
support for the new system. Johnston and Vitale
continue that most organisations are accustomed to
justifying new applications of information
technology only through cost reductions, never on
the basis of increased revenues.
Organisations are ever more developing
technological tools to be used when seeking
solutions to manage knowledge (Schultze & Boland
Jr., 2000). Modern information society presumes
that knowledge is easily and quickly transferred
between participants that need that knowledge
(Loebbecke et al. 1999). Ragowsky et al. (2000)
state that information systems are vital to the
operation and management of every organisation.
The authors have studied how to analyse the benefits
of using information systems. They found no
significant relationship between organisational
characteristics and the prevailing benefit from the
IS. Further, the authors argue that organisations
should expect to gain benefits from the information
systems e.g. cost reduction and increases in
competitive capability.
Developing and implementing an IS are
instances of organisational change (Davis & Olson
1985, Lyytinen 1987) and they often lead to changes
in work processes and structures of the personnel
(Eason 1988, Sahay & Robey 1996). Markus (2004)
has reported about three different ways to carry out
the organisational change when implementing
information systems: 1) letting users not notice the
change, 2) users noticing the new information
systems and 3) both IS and process change and users
notice that.
All shortcomings that impede successful
outcome of the development process lead to stress
and change-resistive behaviours (Lorenzi & Riley,
2003). E.g. adopting information systems may face
problems (Halonen, 2004). The quality of
specifications is essential to the IS that is to be
implemented (Lyytinen & Lehtinen, 1987). Halonen
and Heiskanen (2005) have described in their study
on managing the process of acquisition how
previously made specifications can slow down IS
procurement.
Further, specifications are connected with the
success of the IS project, even if their role can be
discussed (Wateridge, 1998). Wateridge continues
that it is too simply to suggest that a project is a
success if it is delivered on time and to budget. Later
in this paper we discuss how the specifications
influence on time.
3 RESEARCH METHOD AND
STUDY MATERIAL
This study is qualitative research enabling the
researcher to explain and understand social and
cultural phenomena. Baskerville and Wood-Harper
(1998) have assessed action research to be ideal for
studying information systems in practice. Schön
(1983) points out that action research is applicable in
different environments. Action research is
characterised by 1) its multivariate social setting, 2)
its highly interpretive assumptions about
observation, 3) intervention by the researcher, 4)
participatory observation and 5) the study of change
in the social setting (Baskerville and Wood-Harper,
1998).
Greenwood and Levin (2000) describe action
research by four definitions:
1. Action research is inquiry in which
participants and researchers cogenerate
knowledge through collaborative
communicative processes in which all
participants’ contributions are taken
seriously.
2. Action research treats the diversity of
experience and capacities within the local
group as an opportunity for the enrichment of
the researcher/action process.
3. Action research produces valid research
results.
4. Action research is context centred; it aims to
solve real-life problems in context.
In addition, an academic action-researcher
(Lallé, 2003) as a concept belongs to this study by
meaning the researcher working in an organisation
and generating new scientific knowledge. Ayas and
Zeniuck (2001) emphasised “effective collaboration
between academics and managers, thus benefiting
both practice and theory, enhancing the significance
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
484
of research, informing both practitioners’ and
academics’ views and actions”.
Besides action research, the means of case study
(Yin, 2003) are strongly emphasised in this research.
An exemplary case study is characterised by five
features: 1) significance, 2) being “complete”, 3)
considering alternative perspectives, 4) displaying
sufficient evidence, and 5) composed in an engaging
manner (Yin, 2003). The benefit of case research is
in its extension of experience of the researcher
(Stake, 2000). Stake continues that it is essential to
choose a case that offers possibilities for learning
and getting better understanding about
implementation. Therefore this case is a pertinent
choice in this paper. Stake (2000) writes:
“Knowledge is socially constructed [---] case study
researchers assist readers in the construction of
knowledge.”
This research is described as a case bearing in
mind the idea of van der Blonk (2003) when he
states that cases are written with a purpose that
heads to the goal of the research project. He
continues that the researcher is interpreting the case
when writing it down. Writing has also been very
personal and the approach is linked with experiences
of the researcher, following the notes by van der
Blonk (2003).
The research material consists of memorandums
from meetings, emails to the project manager and a
personal diary (Coghlan and Brannick, 2002) written
by the researcher. The nature of the diary is personal
research diary in contrast of being a project protocol.
In the diary there are notes from about 350 days
including personal observations from meetings and
encounters and copied SMS’s from vendors.
In qualitative research studies the benefit of
diaries is realised when writing out the cases
(Newbury, 2001). In addition, the researcher has
made observations when working in the project. The
approach is subjective and interpretative (Walsham,
1993) because the observations and findings reflect
strongly on our personal presence. Mason (2002)
states: “Writing autobiographical and other notes,
keeping a journal, and mentally re-entering salient
moments can assist professional development and be
integral to research.”
4 EXPERIENCES FROM AN
INFORMATION SYSTEM
IMPLEMENTATION
Our empiric material comes from an implementation
project where a joint IS called MoSu was designed
and taken into use by three universities. The goal of
the project was to implement and to pilot the IS that
was to be taken into nation-wide use after the
piloting phase. The aim of the IS was to support the
student affairs officials when they managed student
mobility in their universities, and to enable students
to apply for rights to study using electronic system.
Student mobility happens when a student performs
studies as a part of his or her academic degree in
another university. This right is subject to licence.
Student mobility is increasing between
universities. In June 2003 all universities in the
country agreed that they will allow students to pass
exams in other universities as a part of their master’s
degree. In addition to that, 33 European Ministers
agreed on a unified educational system in Europe
(Bologna, 2003). That is expected to extend the
student mobility over national frontiers in the future.
Furthermore, unified studies may increase student
mobility also nation-wide.
4.1 Background of MoSu
Student mobility had been specified in another
project by other participants and the output of this
previous project was to be used when implementing
this new IS (memorandum September 12, 2003).
The targets of this previous project were to produce
specifications for an IS and to implement and pilot
the designed IS. However, due to lack of resources,
the total output was never achieved and it is out of
the scope of this paper.
The project manager wrote her diary in August,
2003: “When reading the memorandums from the
pilot phase of the IS (“Students’ mobility”) I
understood that I should have read them more often
and more carefully in order to realise what has been
done and what was to be done during the next years.
So far I could not see any pilot and I was the one to
execute the implementation of this IS to be used by
three universities in the first phase.
The most important document that the previous
project had done was the specification of the process
of student mobility. This description of the mobility
was available and useful when starting with the
actual IS implementation. The description included
actions needed by students, student affairs officials
ENABLING OR DISABLING WITH OLD SPECIFICATIONS - A New Information System Based on Old Specifications
485
and invoicing affairs, added with issues connected
with data administration offices in universities. In
addition, also actions connected in registering into
universities and signing in the courses were
described in the process document. The document
appeared to be very useful later when the diversified
nature of managing student mobility was introduced
in several seminars and it realised the high-felt need
of MoSu that was built later.
In parallel with the MoSu project there was a
project that produced a joint application form to be
used nation-wide when applying for rights to study
in other universities. That appeared to be an effort
but the output was thanked and it acted as a basis for
the electronic form that was produced in our project.
4.2 MoSu and Specifications
The first meeting of MoSu was called in June 2003.
The new project was established in order to produce
an interorganisational IS to support student mobility
in universities. The starting point was to pilot the IS
in three universities (Alfa, Beta and Gamma) and
according to the output, enable start-ups also in other
universities nation-wide (memorandum in June
2003). A fourth university (Delta) was called in to
act as a process university. These universities had
already had mutual student mobility and they had
developed processes of their own to manage it.
Knowledge about information technology and
information systems was scarce in the project group.
IS view was introduced mainly by the vendor who
tried to explain what the decisions meant “in IS”. “If
anybody mentions ‘interface’ I’ll scream”, warned
one official in a meeting.
Further in October 2004 there was discussion
about codes in the electronic application form. The
vendor had to explain the differences between
electronic and paper files and how they had to be
considered when implementing the process into the
IS.
Occasionally several discussions about the
functionality and coding them into the process were
felt annoying by the student affairs officials: “You
may do yourself an IS that you can learn to use and
manage the mobility of students for us.” (Diary notes
from a project meeting in March, 2005).
The process of student mobility that was
specified in the earlier phase by other stakeholders
was described using the view of student affairs
offices and the process was specified to include all
actions and functions related to student mobility.
However, the current IS MoSu was designed only to
support student affairs officials and students in
applying for rights to study and to enable the
participants to follow the process. In addition, the
information concerning accepted rights and passed
studies was offered to the student affairs by MoSu.
This project produced specifications on the
application process from the perspective of the IS. In
practice, this meant that the project members had to
specify the process how the application was
managed in their universities.
The process appeared to be difficult to specify.
The project group had to discuss several times in the
meetings about the arrows in the picture and about
the principles that lead to next steps in the process.
Several times the project group had to change the
decisions that had been earlier made (e.g. the
possibility to change information concerning studies
in the target university: disabled in May 2004 and
enabled in February 2005). However, finally MoSu
was coded according to the process and it was taken
into use in spring 2005.
There were controversies about descriptions and
specifications in the project meetings because some
of the project members expected details about the
process (memorandum in June 2004) and the
implementer responded that the old specifications
cover these details. However, the more the
implementer got acquainted with the old
specifications, the bigger grew the need to specify
and update them. Deficiencies in the old
specifications caused delays in the project
(memorandum in April, 2005) and finally the
schedule was changed to meet the work load when
finalising the specifications (memorandum in May,
2005).
It also happened that when MoSu was in use, the
student affairs officials sent emails to the
administrator asking him to perform actions that
were against the process. “Could you please restore
the application No. xxxx that I rejected back to the
process?” (September 2005). The users could not do
the actions themselves because they had to follow
the procedure that was coded in the IS. With legacy
system, they had only taken the application back
from the waste paper basket.
In the project meeting in May 2005 there were
severe discussions how the invoices should be
managed in MoSu. In the old specifications it was
specified as “the system should be able to combine
the information concerning students, studies and
invoices”. However, the current opinion was that
MoSu must not be developed as an invoicing system
but to support the management of student mobility
and to enable electronic application process. This
caused changes to the old specifications. Because
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
486
MoSu should not invoice anything, all interfaces
concerning invoicing had to be removed from the
specifications (memorandum in May 25, 2005).
In addition, also the information concerning right
to study had to be specified and formulated in order
to be saved in the database. That caused discussion
about the student’s right to see all information
concerning the studies. “Damned, sometimes this
visibility of information is ridiculous! This kind of
interaction as in this case belongs only to those
officers that are interacting. I prefer leaving the
possibility out of the system. Let’s interact with the
old phone or an ordinary email.” (Email to the
project manager February 9, 2005).
We gathered feedback from the users during the
piloting phase. The feedback was mostly very
positive: “Really much better than filling and
sending paper forms!” (Student in May, 2005).
Thank you for the good service with student
mobility!” (Student in May, 2005). However, we got
also some negative feedback: “That was not a user-
friendly application form!” (Student in June, 2005).
5 DISCUSSION
IS literature recognises the importance of relevant
specifications on the successful IS implementation
(e.g. Lyytinen and Lehtinen, 1987). Our MoSu
project was a special case because it was to be
implemented using specifications that had been
made in an earlier project by other project
participants. Our research shows that using
specifications that are “ready-made” is not always a
positive issue but may slow down the
implementation project.
The IS was developed keeping in mind the
possible changes in the process and the users were
involved in the change process, following notes by
Markus (2004), Eason (1988) and Sahay and Robey
(1996). The interorganisational learning ladder
introduced by Ciborra and Andreu (2001) was used
when the different processes of the universities had
to be modified to meet a joint IS that was under
design.
In the beginning the project personnel thought
that the previously made specifications were good
enough to be used when implementing the IS.
However, even in the first meetings the project
manager had thought that there are deficiencies in
the specifications (Diary in August, 2003). Despite
that, the prevailing opinion was that the
specifications should be used when implementing
the new IS. The vendors were informed about the
decision and they started their work according to
that decision.
The more the vendors got involved in the
specifications, the more they were convinced that
the specifications needed to be fulfilled and
considered carefully before designing on them. This
was discussed in project meetings where changes
were made to the old specifications. However, all
these decisions based on carefully made estimations
and all these actions spent resources of the vendors.
The application process was discussed in several
project meetings and it was taken into use looking
forward to the comments from the users. The
piloting phase gave good feedback and the process
was to be changed according to the need.
The role of collaboration was emphasised in
every project meeting. E.g. the interfaces between
course information systems in universities and
MoSu were under discussion and the earlier made
specifications on interfaces were removed from the
implementation (memorandum August 24, 2005)
because the student affairs officials told that their
universities are not able to offer the information.
According to Loebbecke et al. (1999), it is
common to wait for information to be easily and
quickly transferred between participants that need
that information. This was the case also in our
project. The student affairs officials needed the
information concerning student mobility when they
made decisions on applying or rejecting rights to
study. Before this IS, the process easily lasted for
weeks.
From the feedback received from both the
student affairs officials and students we could see
that the implementation had been a success so far.
One reason for this success can be seen in the high-
felt need of both the officials and the students. Even
if the main goal was to support the student affairs
officials in managing the student mobility, also the
relief felt by the students was highly appreciated by
the project owners.
We believe that this case serves both practice and
science, giving better understanding about IS
implementations and the importance of
specifications that are used. Further, if specifications
are done in another project by other stakeholders, the
influence of them is not only positive. Our case
shows that getting acquainted with the specifications
spent resources that could have been useful
otherwise. In our case it would have been wiser to
start “on a clean table”.
However, this kind of proceeding is wise if there is
any fear of “one-vendor-trap”. We would like to
emphasise that this fear pays. Because our project
ENABLING OR DISABLING WITH OLD SPECIFICATIONS - A New Information System Based on Old Specifications
487
was decided to be based on earlier made
specifications, we had to act according to those
decisions. We want to conclude that despite those
decisions, our project appeared to be a success so
far.
REFERENCES
Ayas, K. & Zeniuk, N., 2001. Project-based Learning:
Building Communities of Reflective Practitioners.
Management Learning, vol 32, pp. 61-76.
Barki, H. & Hartwick, J., 2001. Interpersonal Conflict and
Its Management in Information System Development.
MIS Quarterly vol 25, no. 2, pp. 195-228.
Baskerville, R. & Wood-Harper, A. T., 1998. Diversity in
information systems action research methods.
European Journal of Information Systems, vol 7, no.
2, pp. 90-107.
Van der Blonk, H., 2003. Writing case studies in
information systems research. Journal of Information
Technology, vol 18:45-52.
Bologna, 2003. http://www.bologna-berlin2003.de/
(Accessed October 12, 2005).
Ciborra, C.U. & Andreu, R. 2001. Sharing knowledge
across boundaries. Journal of Information Technology,
vol 16, pp. 73-81.
Coghlan, D. & Brannick, T., 2002. Doing action research
in your own organization, Sage Publications, London.
Davis, G.B. & Olson, M.H., 1985. Management
information systems: Conceptual foundations,
structure and development. Mc-Graw-Hill Book
Company, New York, pp. 561-601.
DeChurch, L.A. & Marks, M.A., 2001. Maximizing the
Benefits of Task Conflict: The Role of Conflict
Management. The International Journal of Conflict
Management, vol 12, no. 1, pp. 4-22.
Eason, K., 1988. Information Technology and Organisa-
tional Change, Taylor & Francis, London, pp. 107-
222.
Greenwood, D.J. & Levin, M., 2000. Reconstructing the
relationships between universities and society through
action research. In N K Denzin &Y S Lincoln (eds.),
Handbook of Qualitative Research, Sage Publications
Inc., Thousand Oaks.
Halonen, R., 2004. Resisting technical change – three case
studies. International Journal of Innovation and
Technology Management, vol 1, no. 3, pp. 1-15.
Halonen, R. & Heiskanen, A., 2005. Configuring
cooperation: a reflective learning history. Reflective
Practice, vol 6, no. 3, pp. 379-391.
Hearn, J., 2004. Organization Violations in Practice: A
Case Study in a University Setting. Culture and
Organization, vol 9, no. 4, pp. 253-273.
Johnston, H.R. & Vitale, M.R., 1988. Creating
Competitive Advantage with Interorganizational
Information Systems’, MIS Quarterly, vol 12, no. 2,
pp. 153-165.
Kotlarsky, J. & Oshri, I.., 2005. Social ties, knowledge
sharing and successful collaboration in globally
distributed system development projects. European
Journal of Information Systems, vol 14, no. 1, pp. 37-
48.
Lallé, B., 2003. The Management Science Researcher
Between Theory and Practice. Organizational Studies,
vol 24, pp. 1097-1114.
Loebbecke, C., Van Fenema, P.C. & Powel, P., 1999. Co-
Opetition and Knowledge Transfer. The DATA BASE
for Advances in Information Systems vol 30, no. 2, pp.
16-25.
Lorenzi, N.M. & Riley, R.T., 2003. Organizational issues
= change. International Journal of Medical
Informatics, vol 69, pp. 197-203.
Lyytinen, K., 1987. Different Perspectives on Information
Systems: Problems and Solutions. ACM Computing
Surveys vol 19, no. 1, pp. 5-46.
Lyytinen, K. & Lehtinen, E., 1987. Seven mortal sins of
systems work. In Docherty et al. (eds) System Design
for Human Development and Productivity:
Participation and Beyond, Elsevier Science Publishers
B.V., Amsterdam.
Markus, M.L., 2004. Technochange management: using
IT to drive organizational change. Journal of
Information Technology vol 19, pp. 4-20.
Mason, J., 2002. Researching Your Own Practice: The
Discipline of Noticing, Routledge Falmer, London.
Munkvold, B.E., 1999. Challenges of IT implementation
for supporting collaboration in distributed
organizations. European Journal of Information
System, vol 8, pp. 260-272.
Newbury, D., 2001. Diaries and Fieldnotes in the Research
Process. Research Issues In Art Design and Media, no.
1. http://www.biad.uce.ac.uk/research/riadm/ issueOne
/default.asp (Accessed October 15, 2005).
Ragowsky, A., Ahituv, N. & Neumann, S., 2000. The
Benefits of Using Information Systems. Communica-
tions of the ACM, vol. 43, no. 11, pp. 303-311.
Sahay, S. & Robey, D., 1996. Organizational Context,
Social Interpretation, and the Implementation and
Consequences of Geographic Information Systems.
Accounting, Management & Information Technology
vol 6, no. 4, pp. 255-282.
Schultze, U. & Boland, Jr. R.J., 2000. Knowledge
management technology and the reproduction of
knowledge work practices. Journal of Strategic
Information Systems, vol 9, no. 2-3, pp. 193-212.
Schön, D.A., 1983. The reflective practitioner, Basic
Books, New York
Stake, R.E., 2000. Case studies. In N K Denzin & Y S
Lincoln (eds.), Handbook of Qualitative Research,
Sage Publications, Thousand Oaks.
Walsham, G., 1993. Interpreting information systems in
organizations, Wiley, Chichester.
Wateridge, J., 1998. How can IS/IT projects be measured
for success? International Journal of Project
Management, vol 16, no. 1, pp. 59-63.
Yin, R.K., 2003. Case Study Research. Research Methods,
SAGE Publications, London.
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
488