Master’s Thesis

Communicational aspects of
Project Management using
web-based technologies:
Implementing an email-based
communication environment
carried out at the
Information & Software Engineering Group
Technical University of Vienna
under the guidance of
Ao.Univ.Prof. Dipl.Ing. Dr.techn. Andreas Rauber
and
Dipl.Ing. Dr.techn. Alexander Schatten
as the contributing advisor responsible
by
Robert Neureiter, Bakk. techn.
Molkereistrasse 3/7, 1020 Vienna
Matr.Nr. 9925047

Vienna, 10.08.2005
Eidesstattliche Erklärung

Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die
den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht habe.

Wien, 10.08.2005

Acknowledgements

I would like to thank my parents Marianne and Bernhard, my brother Martin and
all my relatives for their support at every point in my life. My study would not
have been possible without their encouragement.

I want to thank all my friends as well, special thanks go to my two comrade-in-

arms regarding university affairs: David and Thomas.

A great support regarding English vocabulary and synonyms was given to me by

LEO [LEO]. Furthermore, the document processor LYX [LyX] helped me to pro-
duce this beautiful LATEX document.

Last but not least I would like to point out the valuable guidance of Dr. Alexander
Schatten during the completion of this master thesis.

i
Abstract

Communication is the central element for successful collaboration of project team

members. Project teams need an adequate infrastructure for exchanging informa-
tion and knowledge. It is not any longer a matter of course that project members
are located at one site: New demands for fast and efficient exchange of informa-
tion arise, whereas the Internet and web-based software applications represent a
possible solution.
This thesis analyses project related communicational aspects and its importance
for project management regarding collaboration, knowledge management and dis-
tributed project management. Supplementary, the implementation of an email-
based communication environment as an extension to an open source project man-
agement tool is illustrated, and also the used technologies are described.

Zusammenfassung

Kommunikation ist das zentrale Element für eine erfolgreiche Zusammenarbeit

von Projektmitarbeitern. Je größer Projektteams werden, desto wichtiger wird
eine funktionierende Infrastruktur zum Austausch von Informationen. Es ist nicht
mehr selbstverständlich, dass sich Projektteams an einem Ort aufhalten: Es sind
neue Anforderungen für den schnellen und effizienten Informationsaustausch ent-
standen, wobei das Internet und webbasierende Softwareanwendungen eine mögliche
Lösung darstellen.
Diese Diplomarbeit untersucht die verschiedenen Aspekte von Projektkommu-
nikation und deren Wichtigkeit für die Zusammenarbeit in Projekten, Knowledge
management und verteiltes Projektmanagement. Anschließend wird die Imple-
mentierung einer E-Mail basierten Kommunikationsumgebung, deren Funktionen
und die verwendeten Technologien beschrieben.

ii
Contents
Eidesstattliche Erklärung . . . . . . . . . . . . . . . . . . . . . . . . . i
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Table of Contents iii

1 Introduction - Project Management 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Why project management? . . . . . . . . . . . . . . . . . . . . . 1
1.3 Benefits of project management . . . . . . . . . . . . . . . . . . 2
1.3.1 Time saving . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Comparability of the project results . . . . . . . . . . . . 3
1.3.3 Personal flexibility . . . . . . . . . . . . . . . . . . . . . 3
1.3.4 Standardisation . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.5 Simplification of communication . . . . . . . . . . . . . . 3
1.4 Tasks of project management . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Controlling . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.3 Team leadership . . . . . . . . . . . . . . . . . . . . . . 6
1.4.4 Organization and communication . . . . . . . . . . . . . 6
1.5 Means of project information . . . . . . . . . . . . . . . . . . . . 6
1.5.1 Common problems . . . . . . . . . . . . . . . . . . . . . 7
1.5.2 Goals of a project related information system . . . . . . . 7

2 Communicational aspects 8
2.1 Project related communication . . . . . . . . . . . . . . . . . . . 8
2.2 Computer supported communication . . . . . . . . . . . . . . . . 9

3 Types of project related communication 11

3.1 Project reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Project documentation . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Direct communication . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Dimensional classification . . . . . . . . . . . . . . . . . 12
3.3.2 Functional classification . . . . . . . . . . . . . . . . . . 13
3.4 Direct communication channels . . . . . . . . . . . . . . . . . . 14

iii
 3.4.1 Meetings, telephone- and video-conferences . . . . . . . . 14
3.4.2 Telephone . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.3 Workshops . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4 Discussion forums . . . . . . . . . . . . . . . . . . . . . 16
3.4.5 Chats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Emails 16
4.1 General information about emails . . . . . . . . . . . . . . . . . 16
4.2 Advantages of emails . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Individual perception of email . . . . . . . . . . . . . . . . . . . 19
4.3.1 Impact to social interactions by email communication . . . 19
4.3.2 Influence on individual level . . . . . . . . . . . . . . . . 21
4.3.3 Influence on organisational level . . . . . . . . . . . . . . 22

5 Distributed and collaborative project management 23

5.1 Advantages of distributed work . . . . . . . . . . . . . . . . . . . 25
5.2 Difficulties of distributed work . . . . . . . . . . . . . . . . . . . 25
5.3 Classification of collaborative project management software . . . 26
5.3.1 Communicative level . . . . . . . . . . . . . . . . . . . . 26
5.3.2 Collective level . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.3 Coordinated level . . . . . . . . . . . . . . . . . . . . . . 27
5.3.4 Concerted level . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Communication in groupware systems . . . . . . . . . . . . . . . 28
5.5 Knowledge development via documentation of communication . . 29
5.5.1 Knowledge management and creation . . . . . . . . . . . 29
5.5.2 Knowledge development via email . . . . . . . . . . . . . 30
5.5.3 Examples for knowledge development via email . . . . . 32

6 Web-based software development 34

6.1 Definition of a web project . . . . . . . . . . . . . . . . . . . . . 34
6.2 Characteristics of web projects . . . . . . . . . . . . . . . . . . . 35
6.2.1 Interdisciplinary collaboration . . . . . . . . . . . . . . . 35
6.2.2 Cost planning . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.3 Broad target groups . . . . . . . . . . . . . . . . . . . . . 35
6.3 Success factors of web projects . . . . . . . . . . . . . . . . . . . 36
6.4 Expense factors of web projects . . . . . . . . . . . . . . . . . . 37
6.5 System- and Security architecture of web projects . . . . . . . . . 38
6.5.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

iv
 6.5.2 Load balancer . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.3 Web server . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5.4 Application server . . . . . . . . . . . . . . . . . . . . . 39
6.5.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.6 An example of a web project: Webmail . . . . . . . . . . . . . . 40
6.7 Web usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.2 Categorisation of usability problems . . . . . . . . . . . . 42
6.7.3 Usability evaluation . . . . . . . . . . . . . . . . . . . . 43

7 Implementing an email-based communication environment 45

7.1 Introduction - Project goal . . . . . . . . . . . . . . . . . . . . . 46
7.2 Needed components . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2.1 Application Server . . . . . . . . . . . . . . . . . . . . . 48
7.2.2 Database Layer . . . . . . . . . . . . . . . . . . . . . . . 49
7.2.3 Presentation layer Struts/Tiles . . . . . . . . . . . . . . . 61
7.2.4 Email systems . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.5 Mail User Agent - JavaMail API . . . . . . . . . . . . . . 70
7.2.6 Message store . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3 Implemented part . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.1 Overall Configuration . . . . . . . . . . . . . . . . . . . 72
7.3.2 User options . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.3 Send mail . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3.4 Email overview . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.5 Email info . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.6 Own POP3-accounts . . . . . . . . . . . . . . . . . . . . 78
7.3.7 Sent mails . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.3.8 Project mails . . . . . . . . . . . . . . . . . . . . . . . . 78
7.4 Usability evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4.1 Critical usability problems . . . . . . . . . . . . . . . . . 80
7.4.2 Minor usability problems . . . . . . . . . . . . . . . . . . 80
7.4.3 Cosmetic usability problems . . . . . . . . . . . . . . . . 81
7.5 Future outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.5.1 IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.5.2 Visualisation of email-threads . . . . . . . . . . . . . . . 81
7.5.3 Full text search of emails . . . . . . . . . . . . . . . . . . 81
7.5.4 Virtual folders defined by extended email filters . . . . . . 81
7.6 Seven theses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

v
References 84

List of Figures 90

List of Tables 91

Index 92

vi
1 Introduction - Project Management
1.1 Introduction
This master thesis describes important project management tasks, especially the
role of communication within a project. An efficient and functional communi-
cation infrastructure is indispensable for project team members which includes
project reporting, project documentation and more direct communication chan-
nels. Several communication channels and their utilization are mentioned. In
particular, emails and their utilisation in project management for project commu-
nication and as a key element for building a knowledge base are analysed.
Moreover, advantages and disadvantages of distributed projects and important as-
pects of collaboration between project team members are illustrated. To improve
project management, groupware systems have to be used, important classification
aspects and usefulness of such applications are mentioned.
Another part of this thesis goes into web-based software development. Such ap-
plications have partially other requirements than ’conventional’ software applica-
tions and need adapted approaches in development. Characteristics, success and
expense factors and the architecture of web projects are described. An additional
chapter deals with web usability, since websites often miss efficient navigation,
user feedback or other usability factors. Especially at complex process operations
it is difficult to provide an easy usable workflow in websites.
The last chapter illustrates the implementation of the email based communica-
tion extension of the open source OSWP-portal [OSW05]. The extension in-
cludes a webmail-client and its integration into the project management portfolio
of OSWP. Project related communication and its archival storage was realised.
All needed components, technologies and protocol are described like Simple Mail
Transfer Protocol (SMTP), Post Office Protocol (POP), the JavaMail-API and oth-
ers.

1.2 Why project management?

To understand the purpose of project management we have to define the term
project. There are several versions of which the following is the most suitable in
my opinion. A project can be defined as an endeavour in which human, material
and financial resources are organised in a novel way, to undertake a unique scope
of work, of given specification, with constraints of cost and time, so as to achieve
beneficial change defined by quantitative and qualitative objectives [NCRJ02].

1
These individual tasks generally cannot be accomplished routinely in conventional
hierarchical line organisations. The organisation structures are changing from be-
ing function-oriented and fixed to be flexible and project team oriented. Nowa-
days, realisation of projects demands presents more and more a holistic approach
to optimize problem solving. Competitive conditions are getting more challenging
than ever and most tasks are characterised with growing complexity and extended
interdisciplinary aspects. For example, new products have to be developed in
project durations which are getting shorter and shorter, whereas market require-
ments and development costs are increasing.
Project management includes organisational, methodical and interpersonal meth-
ods to improve, ease and control achievement of the defined project goals. These
methods also allow to keep the costs and effort low which have to be invested,
although many persons may be integrated in the project. Project management
provides a nominal/actual value comparison and therefore allows to intervene in
good time if problems arise. Existing risks should be detected early so that it is
possible to counteract with according measures in time. To get the success factors
like money, time, resources and quality under control and to harmonise them is
the main focus of project management [Hee93].

1.3 Benefits of project management

First an example: In a company with approximately 95 projects and an annual
budget of about 35 million Euros the following benefits were achieved by intro-
ducing professional project management [Ibi04]:

• Deadline delays decreased by circa 60%

• Quality costs decreased by circa 35%

• Production costs decreased by circa 11%

• Contentment of the project managers increased

By introducing project management methods many advantages can be achieved.

In the following chapters, I will give a short overview of possible advancements.

2
1.3.1 Time saving
By structured planning of the tasks, time can be utilised more efficiently. For
example, if all tasks are assigned in detail to the project team members at the
beginning, there is not much coordination effort needed afterwards and no tasks
are carried out twice. In addition, good project management makes team members
a part of the project. Each member feels responsible for project success which
leads to efficient time utilisation.

1.3.2 Comparability of the project results

Since a project is a unique undertaking, it may be assumed that projects cannot be
compared at all. But projects are usually subdivided into several work packages
or activities, which indeed can be compared to equal or similar work packages of
other projects. This is mainly the case if a company runs many projects parallel.
The comparability of the results is a requirement for project progress statistics, for
instance.

1.3.3 Personal flexibility

Project management provides project transparency and according project docu-
mentation, therefore it is easier to add or change personnel. Thus, the period of
vocational adjustment for new project members is decreased. Besides, all mem-
bers bring in their special skills to the team. This variety of knowledge is espe-
cially valuable within interdisciplinary projects such as software projects.

1.3.4 Standardisation
Workflows, terms, forms, documentation, protocols, etc. can be handled more
efficiently due to standardisation by project management methods. With each
project, these tasks are getting more and more routinely [Did04, Klö99].

1.3.5 Simplification of communication

Due to membership to a project team, communication between its members is
greatly improved. All participated persons and departments benefit from inte-
grated communication enhanced by project management.

3
Usually, the emerging costs of introducing systematic project management meth-
ods are overcompensated by ulterior cost reduction and accelerated project reali-
sation [Ibi04].

1.4 Tasks of project management

Project management can be divided into universally valid management functions.
These processes pose self-contained spheres of activity which have to be observed
during the whole project. To achieve the project goals with project teams, a project
has to be planned, controlled and organized. Furthermore the team needs leader-
ship. The project manager is responsible for coordinating, monitoring and inte-
grating all tasks [Hee93].

Figure 1: Management cycle [Hee93]

1.4.1 Planning
In general, planning is directed into the future preparing decisions and actions.
Thinking ahead and gathering information about the future is an important part of

4
planning. If defaulted, in the middle of the project has to be extemporized leading
to uncertainty whether the project ends with success or failure.

Planning includes [Hee93, GP04]:

• Project strategy

• Project definition

• Risk analysis

• Task structuring

• Quality planning

• Time scheduling

• Resource planning

• Cost planning

• Budgetary accounting

1.4.2 Controlling
Unlike planning, controlling always takes place in the present and relies on cog-
nitions of the past. Controlling ensures that all tasks are accomplished as planned
and adequate countermeasures are established if any disruption occurs.

Controlling includes [Hee93, GP04]:

• Integrated control of quality, time schedule, resources and costs

• Action planning for supervision

• Tracing development of critical success factors and risks

• Arrangement of adjustment actions

5
1.4.3 Team leadership
Working in teams brings some advantages such as increased creativity, productive
competition and accelerated information spreading. Although teams have to be
created, guided and decisions have to be made.

Team leadership includes [Hee93, GP04]:

• Project member selection

• Encouragement of goal acceptance, development and cooperation of the
team members (motivation, coaching, dealing with conflicts within the team)
• Initiating changes and advancement of working conditions
• Precipitating decisions

1.4.4 Organization and communication

These tasks are relevant to the whole project lifetime, and their importance is of-
ten underestimated.

This part of project management includes [Hee93, GP04]:

• Competence and responsibility allocation

• Managing the flow of information (reporting, meetings, documentation)
• Project marketing
• Defining of values, standards and rules
• Arrangement of communication within the project team

1.5 Means of project information

The formation of efficient project information procedures is getting more and
more important during trans-sectoral collaboration in organisations. They are be-
coming one of the most critical success factors of projects. Means of project in-
formation cover all activities and instruments which support exchanging project-
related data and therefore foster collaboration between the persons who are in-
volved in the project.

6
1.5.1 Common problems
Frequently experienced problems regarding project information are:
• The involved project team members talk at cross-purposes, e.g. they inter-
pret same terms differently.
• The project manager or other team members are making decisions without
coordinating or informing the regarding persons.
• As a result of insufficient information about project status, project strategy,
etc. the team members are unsettled or even define their own goals.
• All team members get every project report and are overwhelmed by the vast
amount of information. Thus, relevant details for the individual are difficult
to examine.

1.5.2 Goals of a project related information system

By planning all information flows in a project knowingly it can be assured that
all project members get the information they need in order to achieve their work.
This information should be available in time, include all needed details and clearly
structured. Supplementary, this part of project management also includes es-
tablishing preferably short and direct information- and communication channels.
Independent from the whole organisation, project members need their project-
specific information exchange possibilities increasing decision making and project
cycle. Such a system should also provide project team members with a concised
access to all information regarding the project. The visibility of this information
and the progress of the project is vital to project success.

A possible approach would be [GP04]:

• Definition of recipients of the project related information
• Arrangement of types and frequency of project meetings
• Declaration of rules which regard relaying information within the project
team
• Determination of type and frequency concerning written project reports
• Establishing a common document system for the project

7
2 Communicational aspects
2.1 Project related communication
To identify the meaning of communication we have to understand what communi-
cation is and what it is not. Communication as a general rule is interpreted only as
transmission of information, but that is definitely wrong. Communication is rather
a combination of sending information by the sender and receiving and understand-
ing this information by the recipient. As long as the recipient does not understand
the transferred data, communication has not been established. The project team
members, especially the project manager need the ability to communicate. To be
efficient, you have to put yourself in the position of the communication partner.
For example, it is not possible to explain complex technical concepts to someone
who does not possess the according technical knowledge. The message has to be
translated in a language that this person understands, otherwise you are not com-
municating but only giving a bad lecture.

Many problems arise in the course of a project because of defective communica-

tion between the persons involved in the project. Efficient communication defi-
nitely increases the success potential of the project. For example, it is very im-
portant for the project manager not only to make sure that the project fulfils high
quality standards. These results, positive or negative, also have to be discussed
with all involved persons. A vital part of good communication politics is to reg-
ularly announce the challenges and achievements of the project. Team members
need this information to be proud of their efforts. Informed team members are
much more motivated than unbriefed ones [Sto04].

Communicational aspects of project management cover the three C-s: Communi-

cation, coordination and collaboration [JA00].

• Communication is transfer and exchange of information between commu-

nication partners. This aspect serves as the basis for the coordination of
processes and the collaboration of the project members.

• Coordination is based on the communication processes and include all nec-

essary activities for coordinating tasks during work processes.

• To reach efficient collaboration, the communication processes must lead

to well coordinated tasks and a project-wide agreement on common goals

8
 within the project team.

The communication network in a project team should satisfy the following tasks
[Klö99]:

Exchange of information Everybody knows something, all together know more.

Whether information of the project manager or any other member, project internal
communication should allocate every useful piece of information to anyone who
could need it.

Exchange of experience Everybody has skills to achieve something, all to-

gether can achieve almost everything. If any problem is encountered, it may be
possible that someone in the company, organisation or project team already dealt
with such a problem. These experiences can be shared and much time and money
can be saved.

Mutual assistance and help Many developments of project teams can be reused
in others. Something that is difficult to accomplish in one team, may be no prob-
lem for another one. If the needs of the project are communicated properly with
the available knowledge resources, the project will benefit.

Coordination between within the project team Coordination is based on com-

munication and essential for successful time scheduling, resource planning and
controlling aspects.

2.2 Computer supported communication

The computer evolved from a technical marvel in his early days to a nowadays
practical assistant. First, the computers were used for calculations, then utilised
for information systems such as databases and computer networks. Today com-
puters are revolutionising communication. This change away from conventional
communication methods towards new information infrastructures will affect our
lives, but in which way is not known in detail yet. Experiences from earlier major
technological developments may presume complex consequences. The build up of
a global computer based information infrastructure is under way and irreversible.
Computer supported communication causes shifts in the things we do and in our
way of thinking, too. These new forms of communication have the ability to alter

9
interpersonal relationships and the manner how people communicate with each
other. For example, the dependence on personal relationships is getting more and
more unimportant. Instead of these personal relationships, loyal dependencies are
getting more relevant. These dependencies are based on common aims such as
implementing a new software product, for instance. For this reason, it is very
important that communication partners who are possibly anonymous can trust
each other. The more complex the goals to achieve are, the merrier this aspect
gets involved because complex tasks need ongoing coordination between the par-
ticipating persons. Therefore, computer supported communication will increase
human-computer and decrease human-human dialogues [Fre99].

In summary, the intensified usage of computer supported communication create

some trends, based on an analysis stated in [Fre99]:

Language is slowly volatilising and is replaced by and by with short text state-
ments, graphics and pictures which are understood not only by people who speak
the same language.
Communication via electronic channels lack the ability to transmit common im-
pressions of a conversation like personal perceptions or feelings e.g. sounds,
smells or gestures. For example, in emails communication is reduced to words,
video-conferences only have the ability to include some gestures of the commu-
nication partner confining the quality of the dialogue.
Introducing computer supported communication leads slowly to a transfer of per-
sonal responsibility to computer applications. By inadequate use of e.g. company-
wide deployed software applications, the users more and more blame the software
for their own faults.
Direct forms of communication such as telephone or personal discussions are
more and more replaced by asynchronous statements, briefings or requirements
notified by email or other forms of electronic messages. In addition, these new
communication forms interestingly produce added conversations. Often, the sim-
plest questions, which can be answered oneself by thinking about it, are asked e.g.
in a forum. The answers may induct new questions, new propositions are made
and therefore communication can sprawl unregulated.

10
3 Types of project related communication
Communication is a widespread term, therefore establishing an efficient project
related information system means to comprehend the following three parts of
communication, of which the third one contains direct forms of communication
such as meetings, phone, email, etc. These forms are described in detail.

• Project reporting

• Project documentation

• Direct communication

Nowadays, prior to every communication attempt, an adequate form of communi-

cation has to be selected because more and more options are available. The choice
depends on the purpose, on the number of the participants, the needed rapidness,
the necessary time and effort and the traceability of the dialogue.

3.1 Project reporting

The written documents regarding project communication which contain feedback
for the team members about project events are called reports. Reporting therefore
includes all documents in written form giving all groups of interest orientation
about the project’s progress. The goal of this approach is to show the current state
of the project and predict future outcomes as well. Vocal reports concerning the
progress of the project are not sufficient for efficient and traceable project man-
agement.

Typical project reports are [GP04]:

• Project definition / project specification: The project goals has to be well

documented and clearly specified to avoid misunderstandings.

• Reports about project progress: These reports usually are prepared by the
project manager either during regular periods or when a milestone is reached.

• Presentation documents: Well prepared documents for eventual presenta-

tions e.g. to convince a customer that the project is worthy to invest time
and money into it.

11
 • Final project report: This report is also written by the project manager and
is quasi the last project progress report. Normally, it is presented during the
project meeting also to encourage learning effects for future projects.

3.2 Project documentation

A requirement for targeted project documentation is a practicable order of the
project documents. All project documents have to be easily accessible, which
makes introducing a structure for the project documents necessary. Depending on
the size of the project, the project documentation can vary and should be adequate.

Project documentation usually covers [GP04, Bur95]:

• Project manual

• Project journal: It is beneficial to make notes of the project events, usually

in handwritten form.

• Project related repository which contain e.g. contracts, correspondences,

functional specifications and other documentations.

Part of a project related repository should be for example a project website. Such
a website is a significant instrument for providing the project members with all
the needed information about the project [Sto04].

3.3 Direct communication

In this chapter I would like to combine direct forms of communication which are
not documents or reports like described in the previous chapters. Two approaches
of classification are mentioned. Examples will be depicted in the next chapter.

3.3.1 Dimensional classification

Areal aspects cover whether the dialogue partners are located at the same place
like a face-to-face meeting or not, like an email discussion.
Chronological issues can be distinguished between synchronous and asynchro-
nous communication.
Synchronous communication is taking place simultaneously, the dialogue part-
ners are interacting instantaneous. The advantage of this form of communication

12
is that arising questions can be cleared instantly. The messages are not explicitly
stored in the channel.

Examples of synchronous communication methods are:

• Face-to-face meetings

• Chats

• Instant-messengers

• Voice-over-IP conferences (phone or video)

Delayed communication is called asynchronous. The message may be stored in

the channel before being delivered to the recipient. Dialogue partners react at
different points in time on each other. The biggest advantage of asynchronous
communication is that the dialogue partners do not have to be available at the
same time. Nevertheless, this circumstance may lead to misunderstandings or
misinterpretations as the dialogue partners cannot ask immediately if there is any
unclarity. Examples for this form of communication are:

• Emails / mailing lists

• Discussion forums

• Newsgroups

3.3.2 Functional classification

This classification refers to the role of communication. The following types are
described [col05]:

Messaging systems They allow the exchange of messages whereat the partici-
pants cannot communicate synchronously. The management of the messages can
be supported by several features such as additional information attached to the
message. The most classic messaging system is email.

13
Conferencing systems can be subdivided into three classes:

• Non real-time: A group of persons exchange messages between each other.

The messages are always created by one of the participants, but answered
by anybody of the dialogue members. An example for this are newsgroups.
• Real-time: A group of persons is simultaneously talking and exchanging
messages respectively via a network. Electronic data is transmitted sep-
arated from the messages and handled by a groupware- or an individual-
application. Visual data is usually not included. An example of real-time
messaging are chats.
• Teleconferences: This type is synchronous and audio and visual information
is transmitted as well.

Information systems These systems provide structured data for the users and
can be retrieved by according access mechanisms. Information has to be adminis-
trated by adding, changing and deleting content.

3.4 Direct communication channels

In this section I will list the most important channels which improve communica-
tion in project teams to support successful project management. Communication
is more and more globalised by new forms of exchanging information.

3.4.1 Meetings, telephone- and video-conferences

A central success factor is the type and quality of informal verbal communica-
tions, occurring either planned or coincidental. Meetings are the most common
way of communication and usually the best one. They serve as a forum to improve
interpersonal relationships, include gestures providing a better way to make one’s
point of view clear and feedback from the participants can be responded immedi-
ately. The needed information is exchanged at once. Also by the way-comments,
which are important but often forgotten, are proclaimed more easily. Moreover,
last minute changes are hardly communicated. In these cases, a personal meeting
is the best approach. In all these examples a meeting is a much more efficient use
of time [Sto04].

There are two types of face-to-face meetings [McG00]:

14
Individual meetings are usually attended by four people or less, mostly only
two. These meetings are used to get specific and detailed information from each
other. It is easier to solve problems especially if additional questions are coming
up.

Cross-functional meetings are ment to get an overview of the project and there-
fore persons from different areas may participate. Such meetings need a begin
time, an agenda and a specified finish time.

Basically, meetings create practically no misunderstandings between the partici-

pants and are therefore the best way to resolve problems fast and direct. However,
this form of communication is the most extensive type and needs the longest av-
erage lead time [Sch00].
Telephone and video conferences are also very helpful if the participants already
know each other. This synchronous form of communication can be established as
one-to-one of multipoint conference including three or more persons. While di-
recting such a conference, some rules should be noted. For example, only one per-
son may speak at a time, a sequence of speakers also would be beneficial [Sto04].

3.4.2 Telephone
The telephone is one of the fastest and most direct forms of communication if
the dialogue partner is available. Nearly everybody uses telephone as a fast and
reliable communication channel to get information or inform another person about
something of importance. Compared to personal meetings, telephone calls are
usually briefer and are used rather as call backs for deadlines or meeting times.
They are less time consuming and leave less space for misunderstandings than
emails. Disadvantages are of course the lack of traceability of the call or the fact
that the called person is not available in the moment of the call and, on the other
hand, torn out of his work.

3.4.3 Workshops
In workshops the project team members develop detailed plannings, e.g. defining
work packages and assigning them to team members at the beginning of a project.
Workshops usually last at least a day, or sometimes several days [Sto04, GP04].

15
3.4.4 Discussion forums
Discussion forums are an asynchronous way of exchanging information. When
entering a forum, a list of all postings is shown. Each thread contains a starting
message and its answers. A participant can either create a new thread or respond
to an existing one. Forums can be opened or restricted, are either facilitated or
not. A special form of such forums are newsgroups. These are public discussion-
and information forums in which news are exchanged. Each newsgroup covers a
specific topic. News are organised hierarchical and you have to be registered to
the corresponding news server to access to it.

3.4.5 Chats
Chats are by reason of their instantaneous and direct form of communication pre-
ferred for short arrangements. In a chat any number of participants can attend, but
they should follow established rules for chats. These rules are called chatiquette.
Chats are organised in chat rooms or channels and the communication is usually
logged by the chat server. A specialised form of chats are instant-messengers
like ICQ. These programs provide personalised chat functions for communicating
favoured with friends or colleagues.

4 Emails
4.1 General information about emails
As emails are an important part of my diploma thesis, this type of project related
communication channel is described in an own chapter.
The significance of emails is getting more and more important due to the spreading
of computer networks all over the world. Nicholas Negroponte even states "that
email is the most important application in computer networks" and makes the case
that emails will create a totally new worldwide social arrangement [Neg95].

Electronic mail, to everybody known as email, name a letter like message carried
forward via computer networks like the Internet and is the most popular Internet-
application beside the World Wide Web. The first email was sent in 1971 via the
Internet predecessor Arpanet by Ray Tomlinson. It did not take long for this new
application to overhaul other applications such as Telnet or FTP with its trans-
ferred data volume contradicting to Lawrence Roberts who said that the exchange

16
of messages among computer network users are not an important motivation for
a network of scientific computers. Due to the fact that emails are usually sent in
plain text, they are more similar to post cards than to letters. Basic email technol-
ogy does not include features like encrypting, signing or registered letters. Nowa-
days, more precisely since 2002, more than a half of the worldwide emails sent
are spam, making these missing features necessary to avoid anymore useless email
traffic [Wika].

All email addresses have the following format: admin@oswp.info

The address begins with the unique identifier of the user, separated by the charac-
ter "@" from the second part which contains the users network address [Kin97].

4.2 Advantages of emails

Today, more and more employees in companies or universities make reading and
sending of emails a top-priority in their daily schedule. Email messages are in-
creasingly preferred instead of other communication channels because of some
simple but effective advantages:

One of the greatest benefits of email is the fact that the recipient can decide when
to answer. When sending information, emails are eventually faster than the tele-
phone because emails are brought forward even if the recipient is not available at
the time. In addition, replying to an email is much easier than to a document in
written form. Responding is possible via one mouse-click, the message transfer
occurs in seconds, no paper or envelopes are needed and the recipient is able to
read the message whenever he has time to do so. This advantage of timing the
answer as recipient decreases the stress factor which is at hand by telephone, es-
pecially cellular phones. Email messages are appreciated by many people for
well-defined straightforward questions which can be answered clearly without
misunderstandings. Furthermore, emails are so popular because they are asyn-
chronous and readable on the computer. They create enormous mobility, as the
location both of the sender and recipient is not important. Besides, emails are di-
rect and avoid conversations. If there are any interpersonal conflicts between the
dialogue partners both can stay impersonal and businesslike easier.
Of course, asynchronous communication is also possible with the answering ma-
chine of the telephone. It is also a question of preference which type of commu-
nication is chosen: verbal or written form. Nevertheless, regarding the content of
communication, emails are the more beneficial way. Further processing particu-

17
larly archiving the message content is much more comfortable and space-saving
than other communication channels. Supplementary, the concentration of the di-
alogue partners is not affected the way they are during telephone calls. Answers
can be phrased without stress and written at any time.
Additionally, a record of the whole communication is also possible. Email mes-
sages are instantly stored and documented in a database allowing easy project
traceability, for instance. This digital availability of email allows further process-
ing with little time and effort.
Email is not limited to plain text, the sender may add various files to the mes-
sage which are called attachments. Although there are no limits regarding email
size, the mail provider usually sets a limit not to exceed appropriate mail traffic.
In addition, by using HTML-mails the sender is able to format fonts, colours or
insert pictures into the message. Nevertheless, these HTML-mails are ill-reputed
because they pose security risks if for example JavaScript is included in the email.

Emails can be used for several purposes. An example for email utilization would
be newsletters which are very useful for regular status reports sent to a broad target
group, for instance.
Another alternative of emails are discussion forums. The only difference between
conventional email messages and such forums is the fact that in a forum the dis-
cussion thread is easily accessed and all answers to each post is shown. Each user
can answer questions or ask some. Forums are helpful in supporting team work,
especially if the team is separated by open ground. These email flows can be
analysed to combine people with similar interests or skills to according mailing
clusters, for example.
Many email-clients support indexing and searching features which help the user
to manage the information overload created by the intensive use of emails nowa-
days. Usually, filters can be defined to classify emails and file the message in an
according folder in order to handle this challenge [Fre99].

Summarizing, the key characteristics of email contain six advantages [Bae93]:

• Email is asynchronous

• Email is fast

• Email is text-based

• Email can be addressed to multiple recipients

18
 • Email has a built-in external memory

• The external memory can be processed by computer

4.3 Individual perception of email

By using email as a communication channel, there are many important factors
arising which influence individual perceptions. Examples are improved produc-
tivity by better supported group work or collaborating across varying time zones.
On the other hand, extensive use of emails by employees in a company may lead
to shortened network performance or helping software viruses to sprawl.
In this chapter some examples of how people had to adapt since using emails
for communication, how email communication influences people at an individual
level and at an organisational level are given. Impact to social interaction by email
communication is discussed first.

4.3.1 Impact to social interactions by email communication

The increasing use of computer supported communication has its price. With all
its possibilities, advantages and its popularity, email communication also affects
social interactions in companies, universities and private environments.
All these environments are sociological entities including manifold and sensitive
social relationships. For example, the efficiency of a company depends on healthy
interpersonal relations between the employees, their contentment and their mo-
tivation called working atmosphere. Computer supported communication, espe-
cially emails, have a great impact on this system of social interactions. It is es-
timated that computer supported communication decreases interpersonal contacts
by 40 or 50 percent. Physical presence is replaced by tele-presence. Interchange
of ideas over these new communication channels miss the social or situational
conditions which usually rule group dynamics. In common, emails provide no
information about job title, social status, age, look etc. By sending an email, the
dialogue partners usually prefer directness. A problem with email based commu-
nication is the difficulty to distinguish between personal conversation and formal
correspondence. Emails always drift among these two forms leading to possi-
ble misunderstandings. People possibly write statements which they never would
have said in a direct meeting, because of the certain anonymity of emails. Or oth-
erwise, the sender feels that he is in a conversation and includes comments which

19
are uncommon for formal correspondences and the recipient may be grieved.

Email discussions are a good example to show the differences between conven-
tional and computer supported communication. Advantages of email discussions
are that the participants are answering more evenly and more proposals are made.
In normal group discussions usually only few participants speak. But there are
considerable disadvantages regarding social relations as well. The open and not
restrained dialogue via emails complicates democratically decision making. An
important circumstance of email communication is the fact, that nobody can cut
somebody off. Experiments show, that groups of three persons need quadruple
time for making a decision with emails in comparison to direct contact. In addi-
tion, if email linked dialogue partners are pressed for time, the decisions are more
extreme and polarized, or even sometimes no solution is found and no decision is
made [Fre99].

An experiment which analysed the difference between conventional discussions

and email discussions held by software engineering students is described below:
The experiment has been carried out by a professor who teaches computer ethics
courses at the University of Montana [Sch98]. It lasted two semesters and in-
cluded six email discussions. Each email discussion lasted two to three weeks.
He hoped that discussions held via email would solve some problems of in-class
discussions such as domination by few members or blindfold arguments by the
students. For the first two discussions the professor established a detailed set of
rules for posting messages: How many emails the students had to contribute or in
which timeframe they had to post and to respond to messages. This approach was
not very successful, all students answered in one or two days after an email was
posted, but it ended in a question-answering game in which the professor posted
the questions. Most of the students only reposted opinions of others in order to
reach their quota. During the next two discussions these restrictions were can-
celled, although the students did not interact very well. The crucial improvement
of these discussions was the introduction of a facilitator to the last two discussions
embodied by the professor himself. These discussions produced great interaction
between the students and boosted creativity and critical thinking. The students
even complained about the multitude of received emails.
The results of the experiment included both advantages and disadvantages and
are focussed on the last two discussions. Great advantages were that the students
learned more about computer ethics than any class had learned before them. They
looked into the subject before giving a statement. This led to much more reasoned

20
arguments and the students did not copy statements from others but phrased their
own thoughts. On the other hand and as already stated, email discussions are not
capable of transmitting visual or other sensitive impressions making interpretation
of statements more difficult than in conventional discussions. Synchronisation of
the discussion is not trivial, because every participant can answer at any time to
any statement. Therefore, any participant has to keep track of the discussion, oth-
erwise disorientation is possible. The larger the group of discussion members, the
harder this might be. An in-class discussion is more structured. Another disad-
vantage is the difficulty not to get off the subject if the moderator does not react
quickly to prevent this. Additionally, some inactive students had to be motivated
by the moderator to contribute to the discussion.

4.3.2 Influence on individual level

In modern companies and also in academic circles functional teams instead of
unique specialists work together. Email has proven as a worthy tool to contact
every member of these teams simultaneously. Efficient work is strengthened, all
members contribute their ideas to the community via a communication channel
which is easy to handle especially when these teams are locally scattered.
Organising meetings of scheduling other activities is simplified. In the case of
organising a meeting, the responsible manager only needs to send a short email
and the recipients can simply agree or reject the invitation. Important is the fact
that the workflow of the addressed persons is not disturbed in this case.
Using the advantage of recording all communication which is sent via email, some
companies have introduced policies of monitoring the email traffic which is sent
by the employees. The individual employee feels that emails are private like a
personal letter and should not be monitored, whereas the employers claim the op-
posite because the email content should refer to company issues and is therefore
relevant to company’s interests [PCP04].

To sum up, the individual level is influenced as following [PCP04]:

• Reduced time when contacting team members, other managers,...

• Group work is supported very well

• Communication over great distances or time zones is no problem

• Email communication replaces personal contact

21
 • Monitoring of the email traffic mainly decreases email usage for personal
matters

4.3.3 Influence on organisational level

On the organisational point of view, companies are worried about the amount of
time which is spent for email activity by its employees because a notable part
often includes non-business conversation. The bigger a company grows the more
difficult it is to define which emails are business-related and which are not. For
example, it has become naturalised to send and read fun mails or jokes during the
office hours. This behaviour improves the working atmosphere on the one hand,
but otherwise decreases efficiency and work time on the other hand.
Furthermore, the management has to deal with democratization effects on the
company because emails tend to ignore social and hierarchical gaps. In addi-
tion, any member of an organisation can easily communicate his personal opin-
ions about any subject taking control away from the management. A by-product
of this eased conversations are intensified gossips about co-workers including per-
sonal comments about them. Even though the intentions of the sender were not
ment to be offending, they are usually picked up that way.
Another concern from the organisational point of view is the potential of spread-
ing software viruses through the computer network. Despite deploying antivirus-
software, it cannot be assured that none of the employees opens infected files.

To sum up, email communication has the following impacts on organisational

structures [PCP04]:

• Narrows bandwidth of the computer network

• Infestation of software viruses are potential

• Record of all messages

• Control by the management over organisational behaviour is partially lost

• Reduced efficiency due reading fun mails and using email in unprofessional
way for private messages

22
5 Distributed and collaborative project management
Fundamentals of project management are changing by reason of business global-
isation. In past project management approaches, few individuals, located higher
in the organisational hierarchy than the common project members, had the total
overview from the project. Individual project members only knew their tasks and
had no authorisation to make decisions. This procedure only works in repeatable
process environments of course.

"Traditional project management focuses on a single project at a sin-

gle location and is more concerned with project inputs and outputs
than with the project work itself. Traditional project management
emphasizes scheduling, planning and tracking." [NCRJ02]

Nowadays project hierarchies are often more flat and every project member brings
in his own opinion and creative thoughts. In addition, an increasing number of dis-
tributed projects are conducted which involve project collaborators from different
sites.

Three main project types can be defined [NCRJ02]:

• A single project accomplished at a single location

• A single project accomplished at distributed locations

• Multiple projects accomplished at distributed locations

Distributed project management needs some extensions additional to schedul-

ing, planning and tracking like sharing resources, coordination and collaboration
across different locations making communication an important factor.
Nowadays, there are flexible teams whose experts spend a lot of their time to
communicate with those from other departments instead of inelastic division of
work without ongoing communication between experts. The globalisation of the
software development process results eventually from the geographical and tem-
porally (different time-zones) separation of the project team members. Therefore,
distributed collaboration is necessary to achieve the defined project goals.

The three greatest challenges for distributed project management are [FC03]:

23
 • Collaboration: provide qualitative levels of communication, interaction and
coordination.
• Knowledge management: obtain and share explicit knowledge
• Task scheduling: especially the analysis of task interdependence

Some reasons for the use of distributed teams are [PL00]:

First of all, distributed teams are nowadays often unavoidable, especially when it
comes to software development. It is not possible to have all the specialists for
every task at one location. Companies often have several locations all over the
world or work together with other companies. Universities also do not always
have all experts who are needed for specific tasks. Some experts are not needed
full-time and are possibly working at many projects at many locations simulta-
neously. Collaboration over great distances has become reality. This is the most
serious aspect when it comes to distributed teams, but there can be additional
circumstances.
When developing software applications, the clients often request the presence of
at least one project member at their site to have a direct contact person. This
approach often improves the information exchange with the client. However, the
project team has to deal with its local separation.
In some cases, project members are reluctant or unable to relocate to other loca-
tions.
Sometimes it is simply to expensive to get all project members to one location, for
example because there is not enough office space for the whole team. On the other
hand, it might be possible that technical resources are needed which are available
only at different locations.
Most software projects, except small ones, involve many people which leads to
increased communication efforts. Project success depends on the quality and uti-
lization of the communication channels which are used in the project team. In
larger projects, it is beneficial to have a highly organised proactive coordinator for
making suggestions for improvements, managing opinions, summarising conclu-
sions and presenting them for discussion.

For the first project type (single-project, single-location) only common project
management resources such as basic communication (e.g. meetings, phone,...),
coordination tools (e.g. for supervising project progress, scheduling, resource
planning) and information sharing (e.g. document management systems) are needed.

24
Distributed locations additionally afford the technical infrastructure to provide in-
ternet or intranet connections and possibly interoperability between different com-
puter systems to communicate efficiently. The second (single-project, distributed-
location), and even more the third project type (distributed both project and lo-
cation), include all the problems of distributed project management as mentioned
above. Utilised project management tools need to support advanced features such
as cross-project calendaring or prioritization schemes to coordinate the compli-
cated activities arising with this project type. Groupware systems for distributed
project management are described in the next chapter [NCRJ02].

5.1 Advantages of distributed work

Distributed software engineering has the advantage of greater formality within the
team than in single-side located teams. Separated project members keep their in-
formal relationship with their colleagues at a minimum. Processes have to be well
defined and interactions need more discipline. Both processes and interactions are
formalised into detailed documented procedures resulting in more stable project
environments.
Distributed teams have an overhead of communication. For this reason, rather
simple questions are communicated which are mostly answered briefly and re-
lated concisely to the topic minimising disruptions in core work. Usual ’walk-in’
questions in conventional project teams often result in small talk or other non
project relevant talk.
By decomposing project tasks into well separated functions, the results of the
project can also improve. For example, keeping the development staff separated
from the testing staff. This leads to more independent test scenarios and therefore
to a greater chance of finding errors.
An interesting human behaviour is the natural competition between different project
sites. Every location wants to look good in comparison to other locations and tries
hard to complete its tasks in scheduled time and in good quality to outperform the
other sites [PL00].

5.2 Difficulties of distributed work

Distributed cooperated software development makes great demands on the mem-
bers of the project team by restricted face-to-face communication. The resulting
problems regarding coordination have to be dealt with intensified communication
to ensure efficient work and to avoide wasting resources. The project managers

25
effort increases, as it is not naturally to get feedback from other team members
at short notice because this person possibly works in another time zone. It is not
possible to arrange meetings easily, they have to be virtual. In those meetings, the
interaction of the participants is limited and the decision making process is more
complicated.
Another problem are maybe different languages spoken by the team members. A
common language but also common terms and expressions have to be defined be-
tween the project members to avoid misunderstandings or misinterpretations. The
absence of personal contacts hinder developing relations, especially if different
culture groups are involved.
Furthermore, different locations often use different tools and infrastructure such as
different word-processors, email systems, operating systems and hardware. These
varieties also complicate efficient collaboration [col05, PL00].
To assist project team members in their collaboration efforts and needs, project
management tools, which support features described in the next chapter, are re-
quired.

5.3 Classification of collaborative project management software

There are many applications for every needed task in distributed project manage-
ment related to collaboration and knowledge management. Nevertheless, most of
them only support a part of the needed features. For example, telephone calls and
email discussions provide flexible communication. But it is often difficult to filter
out the content and information of this communication and archive it afterwards.
Or on the other side, knowledge development can be carried out with electronic
documents but the storage structure lacks of clarity and it is difficult to find the
needed documents subsequently [FC03].

A collaborative PM-software should ideally support all needed features for dis-
tributed project management and can be classified into four levels. Each ongoing
level is based on the lower level including all its abilities.

5.3.1 Communicative level

Software on this level is mostly web-application-based and only supports the most
basic file sharing features via a central knowledge repository. All project members
can exchange documents or information across one common repository. Since

26
there are no further interaction possibilities, this level only provides the most basic
tasks such as informal communication, information sharing or short dialogues.

5.3.2 Collective level

This level includes a repository for information storage, tasks and timelines, and
resource tracking as well. The project members have minimal overview of the
work of the others, but each team member makes individual efforts. Therefore,
team member interaction is still very limited and this level of collaboration is only
adequate for single-location projects where the tasks of the project are only loosely
coupled. Applications of this level usually support scheduling, resource and task
allocation, milestone process tracking and project-related information storage.

5.3.3 Coordinated level

Team members still make individual efforts, but the success of them can depend on
the accurately timed receipt of efforts from other project members. Real project
collaboration begins on this level. People have to cooperate and interact much
closer, although the users are restricted to sequential execution of project tasks.
For instance, when a document is co-authored by more people, only one person
is working at the document at one point in time. Tools accomplishing this level
provide its users with features such as creating, sharing and reviewing project
documents, checking calendars and coordinating schedules between each other
and reviewing tasks.

5.3.4 Concerted level

At concerted level, all project team members have to focus on the group effort.
The performance of each single member influences the performance of the others,
similar to a rowing team. Software of this level of collaboration includes paral-
lel co-authoring of documents, simultaneous group problem solving and flexible
decision making and document version control. Relevant project information is
linked together and every project member can search, retrieve, upload and update
documents for which he has the authorisation to do so. Such collaboration soft-
ware allows efficient management of distributed projects.

Advanced project management software should at least support the first three lev-
els, because the lower levels only provide information sharing which is insuffi-

27
cient for efficient collaboration between distributed project teams. Members at
different locations depend on other people doing their job and therefore the inter-
action between them is essential, making concerted level applications necessary
[NCRJ02].

5.4 Communication in groupware systems

Groupware is the implementation of a tool which supports theoretical basic princi-
ples of computer supported collaboration called computer supported cooperative
work (CSCW).

"Groupware is distinguished from normal software by the basic as-

sumption it makes: groupware makes the user aware that he is part
of a group, while most other software seeks to hide and protect users
from each other. Groupware is software that accentuates the multiple
user environment, coordinating and orchestrating things so that users
can ’see’ each other, yet do no conflict with each other." [Bae93]

Most of the project management tools and groupware systems which are used
today were developed to fulfil all requirements of non distributed project man-
agement. With today’s demands of collaborative applications accessible over the
Internet, groupware systems have to be integrated into project management sys-
tems which are used. A groupware system supports a group of collaborators who
conduct a common goal. To reach this goal, this groupware system must have the
following features: coordination, collaboration and communication. Communi-
cation is the base for achieving coordination and collaboration, as already pointed
out before. Therefore, the design of the communication features is the most im-
portant part of the system. Other important features are awareness, sessions and
user administration and notifications.
In computer-mediated communication (CMC) systems the following elements are
involved: a sender, a recipient, a message and a channel. Every groupware system
normally has multiple ways of message addressing, for example point-to-point
and multicast, synchronous and asynchronous.
The groupware system should support every communication scenario which could
be used in the project team. Ideally, every project member gets a feeling about
what is going on in the project by using the groupware system [JMH02, FC03].

28
5.5 Knowledge development via documentation of communi-
cation
Collaboration backed by communication is one point, to benefit from it after-
wards is another. To retrace the acquired information through communication of
the project members, the collected knowledge has to be stored in a central well
structured knowledge base.

5.5.1 Knowledge management and creation

Newly created knowledge is more and more viewed as a very valuable source for
companies and their project teams, universities, etc.
To provide the needed information for project members, especially the project
manager, Davenport lists the following characteristics which have to be accom-
plished to be usable [Ank99]:

• Accuracy: Is the information correct?

• Timeliness: Is the information up to date?

• Accessibility: Is the needed information easy to find?

• Engagement: Is the style and medium of the information adequate for its
audience?

• Applicability: Is the information related to the upcoming work?

• Rarity: Does this information provide a competitive advantage?

Knowledge management is a collection of practices which include creation, organ-

isation, access and use of obtained knowledge. This knowledge may cover prod-
ucts, systems, processes, etc. In our globalised world, knowledge management
has become essential to assure successful competition. Knowledge development
is possible via socialisation, externalisation, internalisation and combination. Col-
lecting knowledge assets is a central aspect of every company. Knowledge repos-
itories are very beneficial for project members, especially in distributed virtual
teams. These repositories allow team members to exchange and share knowledge
[Leo98, Ank99, Lic04].

29
5.5.2 Knowledge development via email
Technical communication can play an important role in this area. It is undergo-
ing a transformation nowadays with the rise of the World Wide Web. Knowl-
edge is spread more and more through (technical) communication. Collabora-
tive distributed work increases the importance of knowledge sharing and creation
between the separated project team members. This aspect is called knowledge
management and required to improve the organisational learning effectiveness
and global competitiveness. Knowledge can be obtained by using communica-
tion technologies more effectively. Information is mostly transferred and stored
electronically, nowadays. From a business and educational point of view, the In-
ternet has become a digital schoolhouse alternative knowledge base for its users
[Leo98, Ank99, Lic04].

Today, email is a well-established communication and collaboration channel, but

email can be more than a communication channel. It is increasingly getting im-
portant as a key tool for knowledge development and creation during employing
analysis of email conversations as approach. In dedicated knowledge management
projects, the project members have to invest their resources explicitly in knowl-
edge work and many people are not motivated to do this extra work. Email has the
advantage that it is utilised for many things. It is not necessary to conduct explicit
knowledge development because email integrates knowledge management with
normal work practices. It is used for several purposes in project management, for
example activity recording, organising, meeting scheduling, assigning responsi-
bilities, file transfer, referencing to digital resources, decision making, etc.

For example, if a project member asks for help via email, the recipients are com-
mitted to read the message and, when suitably, respond to it. Replying to emails
in quoted form has become a common way. This electronic record-keeping is in-
creasingly relevant not only for accountability, but also for legal aspects. During
many of these email discussions knowledge is created not only for the project team
in the whole, but also for each project member in particular. Although knowledge
development is not supported best by email, nonetheless email conversations build
spontaneously and naturally new knowledge.

A typical knowledge development cycle from email discussions contains the fol-
lowing processes leading to new knowledge:

30
Initiation The initial email message can contain questions, suggestions, instruc-
tions, etc. and becomes part of a knowledge trail which consists of related, suc-
cessive messages in one or more so called threads. The initial message usually
contains primarily information, no new knowledge yet.

Crystallisation and sharing During replying to the initial message and its suc-
cessors a knowledge trail, which is also called knowledge-under-construction,
may be formed and it grows in size and information with every message. The
participants share insights, ideas, suggestions, contextual information and other
already existing knowledge along this knowledge trail, crystallising relevant in-
formation. During this process, the significance of the trail increases and the
emerging knowledge usually obtains multiple perspectives, relevance, context,
validation, innovativeness, problem resolution, consensus, clarity, etc. The trail
can widen to more than the initial subject or can be finalised if all participants are
satisfied. Persons who accessed the whole trail possess all the knowledge shared
and created during the discussion. Due to documenting the whole trail and allo-
cating it, knowledge has been created and is shared.

Qualification and combination Participants qualify the knowledge-trail by adding

their comments which is called knowledge qualification. Additionally, they are
combining their existing knowledge with the trail which is called knowledge com-
bination. Knowledge qualification is a very important process, as it helps to dis-
tinguish relevant and correct information from faulty information.

Figure 2: Knowledge creation process

31
The outcome of such email conversations can result in different forms such as
decisions, policies or organised plans. The created knowledge from email discus-
sions can be described as purpose-driven and just-in-time knowledge to provide
project members with it for their everyday work needs, activities and responsibil-
ities [Lic04].

5.5.3 Examples for knowledge development via email

In the following, I will introduce two projects which deal with this issue to show
the possible benefits of email based knowledge development:

MailTack The first project is called MailTack and is an EU-sponsored project

which was finished in the year 2000 and lasted over two years. MailTack was
implemented as a local PC client application using a mind mapping and seman-
tic networks GUI and a relational database. Since it is difficult to find existing
knowledge, especially in large knowledge bases, MailTack tried to categorise the
emails produced by the email discussions to ease finding required information.
The program was able to import emails from a standard mail client program. A
knowledge base was constructed which united message sentences into segments,
defined categories and connected them into constellations, associated segments
with categories and connected segments into conversation streams. The segments
which were extracted out of the messages and the defined categories were the
building bricks of this knowledge base. Through connections and associations, all
segments and categories were directly or indirectly related with each other.

The results of this project were:

Tracing the togetherness of email conversations is a major difficulty and the cat-
egorisation of the segments never exceeded experimental character. The needed
effort to build this knowledge base out of email discussions is usually not avail-
able in daily business. However, the acquired and categorised knowledge became
a valuable contribution for knowledge sharing in teams and collaborative learning
as well [MCB02].

MEME Nowadays, most of the messaging systems which are in use have very
little information about the people in the communication network. These mes-
saging systems can practically do nothing more than simply deliver messages to
recipients prior known by the sender. Of course, this lack of directing messages to

32
according recipients can be decreased by mailing-lists. For example, if someone
needs a Java expert, an email to a java-mailing list could be sufficient. In bigger
companies or universities, those people should be available. But the problem is
that not every member of such a mailing list is an adequate conversation partner
automatically, meaning not every java mailing list member is a Java expert for
our case. Again, the messaging system lacks knowledge about the users. This is
where MEME comes in.
MEME is an adaptive information sharing system which is not only capable of
sending information per email, but it also evaluates the information of the mes-
sages based on defined user profiles or overall preferences. The interesting feature
of MEME is that the system can assign relevant value to information extracted out
of messages and, in addition, send this information to persons who are perhaps
interested in it. MEME creates and administrates user profiles and groups of users
who have similar profiles. By comparing the information of the email messages
with the knowledge profile of the users or groups, the system can additionally
decide who gets these messages. These profiles are adaptive, meaning that they
are extended and tuned by MEME based on the email feedback the users give to
the messages in the system. Of course, the feedback should correspond with their
interests, information needs and own knowledge. The profile and group admin-
istration can also be done manually by a user to improve the classification of the
messages.
To come back to our example with the search for a Java expert: Perhaps there
are persons who have exactly the knowledge you need, but they are on no Java
mailing list or have not entered their Java skills into their profiles. Let us make the
assumption that these required persons however have participated in several Java
projects and communicated in their corresponding project teams via email about
these projects. MEME can take advantage of the information semantics of these
messages by adapting the profiles of these users, making them a contact person for
Java matters without explicit profile administration effort. Regretfully, MEME did
not exceed its educational surrounding but the benefits of such a system is obvious
[MD01].

33
6 Web-based software development
6.1 Definition of a web project
The Internet and its applications, especially the World Wide Web, have become an
integral part of our world and the large number of web users increases every day.
This world wide network supports the collaboration of distributed project teams
and web-based project management tools are a valuable complement to project
management. But web-based applications have to be implemented as well. In this
chapter it is described what web projects are and how they differ from conven-
tional projects [Laz01].

Web projects include creating, changing or expanding a website. A website con-

sists of several web pages which belong to an URL (Uniform resource locator)
and can be accessible either public (Internet-site) or only inside a specific net-
work (Intranet-site). Website are also called portals if the content is very manifold
covering many different functional areas. Portals usually also include many fea-
tures.

Web projects are IT (information technology) projects and design projects as well:

Figure 3: Overlap of IT and design in web projects

A web project can be mainly focused on the technical side, for instance internal
changes of data access methods to the used data source without changing anything
in the user interface. But generally design-driven web projects are also possible

34
like, for example, changing only pictures on a website. Web projects are usually
a mix of both sides, making web projects an interdisciplinary challenge [Sto04].

6.2 Characteristics of web projects

There are only a few but very elementary specific characteristics which distinguish
web projects from others. These differences result in consequences affecting the
whole project management:

6.2.1 Interdisciplinary collaboration

Web projects are interdisciplinary. Computer scientists have to work together
with designers, business economists, marketing specialists and sometimes even
editors and jurists who are responsible for the content of the website. This leads
to extended communication effort in the project team and possibly other depart-
ments. Interdisciplinary teams which are frequently new assembled pose special
challenges to the leadership of the project team.
In addition, the workflow of the project is interdisciplinary as well. Clearly se-
quential workflow like, for instance, Business -> Design -> IT is not possible
when dealing with web projects. All areas are involved at most of the time of the
project and have to interact with each other. Sequential workflow would imply
very long project durations.

6.2.2 Cost planning

Cost planning is never a trivial task when a project is planned. However, there
exist multiple models to estimate project costs. Web projects make this task more
difficult because of the mentioned collaboration of design, IT and other depart-
ments. There is no established pricing model for such projects. Furthermore,
web projects may have higher ongoing costs than other completed projects due to
content management, usability enhancement and hosting of the website.

6.2.3 Broad target groups

Web projects address very different users, Internet accessible websites much more
than intranet accessible websites. Even if the website is defined to one target
group, the users can differ in age, level of education, may possess unequal In-

35
ternet experience and different technical equipment. All these aspects should be
considered when implementing a web project [Sto04].

6.3 Success factors of web projects

First of all, it is a fact that a significant percentage of all web projects fail. Es-
pecially during the Internet hype around the year 2000 many websites and IT-
projects were launched which were either not finished or simply not ready for us-
age. Nowadays, the methods and web-technologies are much more sophisticated
and the time for successful web projects is at hand. After all, it is undoubtedly a
matter of opinion when a web project is a failure. Gartner conducted an analysis
in 2002 of web portals based on two criteria: Are the users of the portal satisfied
and is the implementation effort in due proportion to its benefits [Sto04]:

Project outcome Success probability

The disprofit exceeds the portal costs. < 1%
The portal is not used after all, the costs are
20-25%
limited to the portal costs.
The portal is used insufficiently, this also is a
30-35%
sign for a failure.
The project goals were achieved, utilisation
of the portal also is good but the success is 35-40%
not always recognized.
Everybody knows that the project was a suc-
5-10%
cess.
Success exceeds the highest expectations. < 1%

Table 1: Success probability of web projects

Web projects can suffer from all conventional project problems arising during im-
plementation such as insufficient communication, important decisions are delayed
or not made at all, bad project planning, budget reduction, etc.

Some specific problems of web projects are:

• The IT-department is involved not until after the design is ready noticing
that the design is unworkably.

36
 • Defective content

• The website misses its economic goals.

• Hacker attacks

• The website does not fulfil user-satisfaction resulting in less usage of the
website.

• Unexpected user rushes exceeding the performance of the website.

While IT-problems are already recognised during the project, the website is either
functioning or not. Design problems often appear after the launch of the website,
for example if the user acceptance is low.
When implementing a web-project some procedures are helpful like involving the
user of the website, keeping project durations short or implementing the most
important features at the beginning of the implementation process [Sto04].

6.4 Expense factors of web projects

The expense factors can be divided into one-time and ongoing costs. One time
costs are for example developing the concept, implementation of IT and design,
project management and the costs for the initial content and the IT and usabil-
ity tests. The highest costs often arise after the website is launched and utilised.
These ongoing costs cover investments such as content management, hosting of
the website, operating surveillance and further usability testing. Furthermore, es-
sential updates, upgrades and extensions to keep the website practical and secure
are also needed. From the customer point of view the work on the website has just
begun when the website is launched.

One of the most underestimated expense factors is content management. Although

it is not a part of IT-specialists or designers, they have to ensure that new content
is easily inputted into the website by the editors. Other important expense factors
of web projects are [Sto04]:

• Including new technological approaches such as introducing a new frame-

work for developing dynamic web pages.

37
 • Usage of a content management system, especially if the IT-specialists are
not familiar with it yet.
• When implementing websites, there is often a lack of usability.
• Internationalisation

6.5 System- and Security architecture of web projects

To host a web project, an adequate system-architecture is required which contains
several components such as a web server, a firewall, possibly a load balancer, web-
and application server and a database. In the picture below a widely accepted form
of system-architecture is illustrated:

Figure 4: System architecture of a web project

6.5.1 Firewall
Usually, an own firewall-computer secures the internal network that it prevents
any unauthorized entry. The firewall should be separated from other servers to
keep security risks at minimum. The more services are running on a system the
merrier security links emerge.

6.5.2 Load balancer

A load balancer is only needed when huge web-portals are hosted to divide the
requests of the clients to several web servers. Whereas load balancing is not very

38
complicated regarding static websites, the sites are simply copied on every web
server. Those load balancing systems are sometimes actually integrated in net-
work switches or in small software programs. Handling dynamic portals with
user sessions is not trivial. In this case, the user sessions are either closed when
switching to another server or have to be mirrored to other servers as well.

6.5.3 Web server

A web server is a service running on a computer which publishes the web pages
of a website via the HTTP-protocol. In general, the host computer, on which this
service is running, is also called web server.
The procedure of connecting to a web server takes the following course of action:
A user sends a request from the client via the browser. The browser forwards the
HTTP-request to the web server which processes it supported by the behind appli-
cation server and database. The web server either sends the requested resources
(pages, pictures,...) or, in the case of dynamic pages, first generates the according
web pages and then sends them via response to the client. The standard ports are
port 80 via HTTP and port 443 via HTTPS for encrypted connections.
There are many web servers available today. The best known are the Apache Web
server and the Microsoft Internet Information server (IIS) [Wikf, Sto04].

6.5.4 Application server

An application server contains business logic if required. This software runs ei-
ther on an own computer or as service on the web server, for example. In small
or simple projects the needed logic can also be handled by the web server. Ap-
plication servers come into play if the logical operations are getting too complex
and/or the software application is structured in multilayer like in the J2EE (Java2
Enterprise Edition) framework. Those forms of architecture assure that presenta-
tion layer, business logic layer and database layer are separated. An application
server also decreases implementation efforts because it includes logic which has
to be implemented otherwise separately such as scalability, encapsulation of data
sources, logging abilities, etc.
There are no common guidelines from which point of complexity an application
server should be used. By all means, the utilisation of a commercial application
server increases project budgets enormously. Therefore, free available servers
are a good alternative for middle-sized web projects which need an application
server but are yet too small for investing money for a commercial server. Two

39
examples are the commercial IBM Web Sphere server and the JBoss server which
is available for free [Wikf, Sto04].

6.5.5 Database
On every website data has to be stored, and in most cases a database is used.
Again, there are many options for choosing a database, commercial and free ones.
Market leader is Oracle with its commercial product, but there are free avail-
able alternatives such as MySQL or PostgreSQL fulfilling the required features
[Sto04].

6.6 An example of a web project: Webmail

A combination of web-based software development and making email communi-
cation possible would be the implementation of web based email software. Web-
mail stands for websites providing access to email functions via a web browser.
Many commercial Internet service provider offer webmail as supplement to their
service. But there are also many so called free mail-provider which allow creating
email accounts at no charge like hotmail, GMX or yahoo. Free mail-providers
usually also support access via POP3, IMAP and SMTP for using email accounts
with an email client program. The greatest advantage of webmail is instantaneous
access to the own email account from every computer connected to the Internet
and equipped with a web browser. It would be beneficial for project management
tools if communication abilities supported by webmail were included [Wike].

6.7 Web usability

6.7.1 Introduction
This chapter is alluded because usability plays a vital role when developing web
projects. Usability is a quality attribute that assesses how practicable an interface
is. According to the ISO-Norm, usability is the effectiveness, efficiency and the
degree of user satisfaction in which specified users achieve defined goals in given
environments [MM02]. A usable program or website is easy to learn, efficient to
use and easy to remember. The word "usability" also refers to methods for im-
proving ease-of-use during the design process.

Usability has five quality components [Niea]:

40
 • Learnability: How easy is it for users to accomplish basic tasks the first time
they encounter the design?

• Efficiency: Once users have learned the design, how quickly can they per-
form tasks?

• Memorability: When users return to the design after a period of not using
it, how easily can they re-establish proficiency?

• Errors: How many errors do users make, how severe are these errors, and
how easily can they recover from errors?

• Satisfaction: How pleasant is using the design?

As already mentioned before, when implementing web projects, usability should

get some additional attention because of multiple conditions. Some of them are
[MM02]:

Graphic user interfaces (GUI) have shortened potentials in web projects be-
cause of the restrictions which are given by the World Wide Web and the HTML-
standard. From the technical point of view it is therefore naturally more difficult
to achieve the same usability standards for web projects as for conventional Win-
dows programs, for instance. To keep navigation through a website clearly laid
out and intuitive but nevertheless efficient is one of the most challenging tasks
when implementing web projects. In addition, certain browser incompatibilities
do not make this task easier.

Bandwidth Whereas intranet web projects usually have no bandwidth prob-

lems, many users of the Internet do not have broadband and need websites which
load in acceptable durations. Nielsen states that no user waits for more than ten
seconds when requesting a webpage. On the one hand, web projects should pro-
vide a sophisticated GUI to compensate web-based limitations, but on the other
hand the GUI has to be slim as well to ensure short loading times. These conflic-
tive issues are often not easy to handle.

Content and design When implementing a web project, especially when it is

a commercial website, design and content have to be highly appealing and up to
date. To get users on the website can be difficult, to lose them is very easy. Just
one click, and the user is away. On each webpage only the actually needed content

41
should be displayed. The user must not be confused by amounts of information.
The principle of simplicity known as KISS - Keep it simple and stupid - comes
into play. Also, first sight impressions are very important.

Interaction with the user Getting feedback is no trivial issue in web projects,
because web pages can only react on a users request. For example, a form which
contains many fields should have immediate feedback after entering information,
not until the whole form is filled in and submitted by the user. Unfortunately,
those features require additional features such as JavaScript. If such features are
not possible, detailed and clear feedback has to be given to the user at least after
the user submits the form.

6.7.2 Categorisation of usability problems

"Severity ratings can be used to allocate the most resources to fix the
most serious problems and can also provide a rough estimate of the
need for additional usability efforts. If the severity ratings indicate
that several disastrous usability problems remain in an interface, it
will probably be inadvisable to release it. But one might decide to go
ahead with the release of a system with several usability problems if
they are all judged as being cosmetic in nature." [Nieb]

There is no standardised way for categorising usability problems. Usually they

are divided into critical, major, minor and cosmetic problems [Nie93]:

Critical problems These problems are imperative to fix before the product can
be released. They make the application very difficult to use or even not usable at
all.

Examples for this category are:

• System crashes

• Workflows break down

• Complete loss of focus for a specific task

• Loss of information / data

42
 • The user prevents himself from further use

• An obvious competitive feature is missing

• Missing feedback for critical operations

Minor problems These problems are also important to fix, but normal usage of
the product is not affected. They can confuse users while using the product or
increase the time a user needs for the performance of a task.

Examples for this category are:

• Loss of functionality

• Problematic impact on a person’s workflow

• Layout inconsistency

• Non-standard icons for standard functions / a common menu item or tool

bar button does not do what is normally expected

Cosmetic problems These problems need not be fixed unless extra time is avail-
able on the project. As already the name points out, they are cosmetic and there-
fore not affecting the usage of the product in a disturbing way.

Examples for this category are:

• Inconsistent icons (size, colour, inappropriate associativity) or links (font,

colour)

• Spelling problems

• Non-critical workflow issues

6.7.3 Usability evaluation

Usability evaluation is a method used to understand how users will use software
products. The purpose of a usability evaluation is to predict the expected perfor-
mance of the actual customer using the current product and materials, as well as

43
detect serious problems prior to the release of the product. Usually, such reports
provide proposals to improve the quality of the software.
Usability testing provides business value and lowers the risk of product failure.
For a software product, a low level of usability can increase market risk such as
increasing support costs, failing to meet customer usability requirements, loss of
brand reputation of a company, or products that are late on the market because of
necessary redesign and consecutive loss of market share [Mea02].

Usability evaluations should be performed throughout the product development,

not only prior to launch. It can be performed on designs, prototypes and final
products. It is not necessary to have a complete manual, help system or website to
conduct an evaluation. These tests are possible for prototypes, navigation, outlines
of manuals or help systems, and specific screens or modules [TCF98].
The product has to be examined to expose both large-scale problems and minor
design defects. Therefore, a fairly usability evaluation reduces development time
and costs and increases the satisfaction of the consumers [Nie00].

As a matter of fact, one of the most important motives for usability testing is that
designers or programmers are not the users in the majority of cases. End-users
have to be integrated in the whole development process to ensure high usability
standards. Project members are routine-blinded if it comes to usability evaluation.
It is psychologically nearly impossible to forget or ignore already learned issues
when implementing a design or program. Therefore, such a think back into the
end-users point of view is very difficult for programmers and designers but ab-
solutely necessary for usability testing if no end-users are available. In addition,
project team members are usually computer-experienced and use the computer
and the Internet quite regularly. They are mostly not the users of the website, ex-
cept the website is a portal for designers or programmers. To evaluate usability of
a website and uncover its faults efficiently, the website has to be definitely tested
also by the end-users. These test persons should be ideally users of the target
group. To quote Nielsen: "Designers are not users" or "The user is always right"
[Nie93]. Usability tests can take place for example in a usability laboratory, in a
workplace setting, over the web or anywhere else where the required infrastruc-
ture is available.

There are several options to test usability. Some methods are mentioned below:

44
Scenario-based testing The test users have to complete several predefined tasks
or scenarios in a specific length of time. "A scenario is an encapsulated descrip-
tion of an individual user, using a specific set of computer facilities to achieve a
specific outcome under specified circumstances over a certain time interval (this
in contrast to simple static collection of screens and menus: The scenario explic-
itly includes a time dimension of what happens when)." [Nie00] By performing
the tasks, the test users should find usability problems and document them.

Thinking aloud In this method, the test user articulates his problem, impres-
sions and questions which arise during the usability test. The test user is guided
by an observer who quotes these statements and analyse it afterwards.

Video recording/Video capturing The analysis of both methods is very time

consuming. Therefore, they are only recommended if there are not many test
users.

Questionnaire By filling out a questionnaire, the test user can communicate his
experiences from testing the website.

There are other usability testing methods, and most of them can be combined to
improve the evaluation. A good approach would be: First select representative
test users and set up time and location for the usability test. Then introduce the
test and give the users the tasks which they have to perform. Ask them to attend
the tasks and collect data via videotape, notes or data logging. Conclude the test
with a questionnaire and compensate the test users for the participation afterwards
[MM02, Nie93, Laz01].

7 Implementing an email-based communication en-

vironment
This section covers the implementation of the communication environment into
the OSWP-project which is based on email-messages. Furthermore the OSWP-
project is described, especially which components and technologies are used.
These components include the web server, database, open-source-frameworks
such as OJB or Struts and, in particular, for the implemented part: The SMTP
and POP3-protocols for handling emails and the JavaMail-API.

45
7.1 Introduction - Project goal
"Open Science Workplace (OSWP) started as a Cooperation Project
between University of Kerman (Iran) and Vienna University of Tech-
nology (Austria) financed by the Technology Cooperation Organisa-
tion (TCO, Iran) and the Ministry of Science (Austria). OSWP is
a web-based project-management and communication tool. It sup-
ports (scientific) cooperation, resource management, project moni-
toring and information distribution." [OSW05]

The most important key issues are:

• OSWP is web-based and can therefore be accessed at any place just by using
a web browser.

• The used technologies are platform independent (Java, XML) and there is
no restriction to a specified database because a JDBC capable relational
database system is supported [AS04].

• The features of OSWP include project and user management, communi-

cation environments such as emailing, discussion and a chat. In addition,
resource management is included.

• Finally, OSWP is a full open source project under the Apache license.

The first version of the communication module in the OSWP-portal only included
a simple form where users were able to send a mail to several addresses.
To enhance project-related communication, new features were added. The ap-
proach was to keep a mail history of all mails which were sent through the portal
and enabling of email/project association. This history now allows administrating,
viewing of and replying to messages. Mails are not only sent anymore, each mail
is stored in an eml-file on the server’s file system and can be accessed through the
portal anytime. The possibility of sending and/or assigning mails to projects al-
lows project-related communication. It also provides a growing knowledge-base
for each of the projects. Users can discuss their proposals or problems, for exam-
ple, like in a forum or a mailing list. But they can also address people who are not
registered as users in the system.
Furthermore, every user can configure his own mail-accounts to retrieve mails via
POP3. These mails can also be integrated as project mails by assigning them to

46
the desired project. Additional features such as signatures, contacts and mail fil-
ters have also been implemented.

Figure 5: Feature-overview of the email module

7.2 Needed components

In this chapter all needed components are described. To give an overview, the
client connects via the OSWP-website to the web server by using any browser.
The presentation layer is realized with the open-source project Struts [Apab].
The business logic contains all necessary methods to communicate with the mail
server. Both SMTP and POP3 administrate the emails which are stored on the file
system and communicate with the database through another open source project
called OJB [Apaa]. OSWP runs on an application server named JBoss.

47
 Figure 6: Overview and structure of the used components

7.2.1 Application Server

The foundation of the application which was chosen for OSWP is an abstract,
clearly defined and component oriented platform which is called J2EE (Java 2
enterprise edition) by Sun. The J2EE platform eases implementing applications
by basing them on standardized modular components. J2EE adds full support for
Enterprise JavaBeans components, Java Servlets API, Java Server Pages and XML

48
technology [Sun05a].
For this reason, a J2EE server is needed. JBoss plays that vital role for OSWP.
This server is a J2EE implemented open source software, only documentation
and support are charged. JBoss includes the JBossServer, the EJB-container (En-
terprise Java Beans) and the JMX-infrastructure (Java Management eXtension)
[JBo].
A customized JBoss distribution is available at the OSWP-website [OSW05].

7.2.2 Database Layer

All relevant data of the implementation is stored into a relational database except
the emails itself which are stored on the file system in eml-format. Since emails
with attachments may need much disk space I keep them out of the database.

Database In this particular case PostgreSQL is used. This database is open

source and available under open source license. PostgreSQL supports the SQL92
and SQL99 standard as well as own extensions.

Some of the most interesting features are listed below [Pos05]:

• Operations such as sub selects, outer joins, views, trigger, and referential
integrity and transactions are supported.

• PostgreSQL provides interfaces to JDBC (Java Database Connectivity) and

ODBC (Open DBC).

• Stored procedures can be programmed in SQL or in the extended Postgre

Pl/pgSQL and are compiled and stored on the database server. Therefore,
they assure fast access.

• Binary data can be stored directly in tables as so called large objects.

• SSL-encrypted data communication or authentication with Kerberos is pos-

sible.

Tables The following tables were created to store all the data which is needed
for the new features of the email-communication part of OSWP:

49
mail_email: This table stores a reference to all emails which were sent, received
and assigned to any project. If an email is needed, the corresponding eml-file is
loaded from the file system.

Table attribute Data type Restrictions Description

id Integer Not null Primary key
messageid String Not null Unique id of email
filename String Not null Filename (*.eml)
mailfrom String Not null Sender
subject String Subject of email
sentdate Date Not null Time of sending
sentbyuserid Integer *
pop3accountid Integer **
hasattachments Bit ***

* This attribute is set with the appropriate user-ID, if a user has sent an email
through OSWP. If set, this email is shown via Sent mail of the corresponding user.
** This attribute is set with the appropriate pop3-account-ID, if this mail has been
received by a POP3-account of a user. If set, this mail is shown in the equivalent
POP3-account of the user.
*** This attribute is set, if the email has attachments.

Table 2: Database table: mail_email

mail_mailtask: This many-to-many relationship between emails and tasks con-

tains the information which emails are assigned to which projects.

Restrictions Data type Restrictions Description

id Integer Not null Primary key
emailid Integer Not null Foreign key mail_email
taskid Integer Not null Foreign key task

Table 3: Database table: mail_task

50
mail_mailuser: This many-to-many relationship between emails and users con-
tains the information which emails were sent through OSWP directly to users or
to projects where the users were assigned.

Restrictions Data type Restrictions Description

id Integer Not null Primary key
emailid Integer Not null Foreign key mail_email
userid Integer Not null Foreign key person

Table 4: Database table: mail_mailuser

mail_pop3account: Every user can manage several own POP3-accounts and

receive emails from them. All needed information to log on to the according
POP3-mailserver is stored in this table.

Restrictions Data type Restrictions Description

id Integer Not null Primary key
name String Not null Name of account
servername String Not null Name of host, e.g. mail.gmx.net
username String Not null Name of user
password String Not null Password of account
userid Integer Not null Foreign key person
deletefromserver Bit *

* If set, all emails are deleted from the mail server after retrieval.

Table 5: Database table: mail_pop3account

mail_smtpaccount: Every user can manage several SMTP- accounts and sent
emails through them. All needed information to authorise the user to the accord-
ing SMTP-mail server is stored in this table.

51
 Restrictions Data type Restrictions Description
id Integer Not null Primary key
name String Not null Name of account
servername String Not null Name of host, e.g. smtp.gmx.net
username String Not null Name of user
password String Not null Password of account
emailfrom String Not null Send address of user *
userid Integer Not null Foreign key person

* Example: Robert Neureiter <robert@oswp.info>

Table 6: Database table: mail_smtpaccount

mail_signature: To append signatures to emails easily, every user can manage

as many as wanted.

Restrictions Data type Restrictions Description

id Integer Not null Primary key
name String Not null Name of signature
signature String Not null Signature
userid Integer Not null Foreign key person

Table 7: Database table: mail_signature

mail_filter: Emails can be automatically assigned to projects by a filter while

being retrieved via a POP3-account. If a defined pattern is found in subject, text
or from, the according mail is assigned to the specified project.

52
 Restrictions Data type Restrictions Description
id Integer Not null Primary key
name String Not null Name of filter
filter String Not null Filter
type Integer Not null Type *
projectid Integer Not null Foreign key task
userid Integer Not null Foreign key person

* 1...subject, 2...text, 3...from

Table 8: Database table: mail_filter

mail_contact: A simple contact list can be administrated to address people who

have no system account and is stored in this table.

Restrictions Data type Restrictions Description

id Integer Not null Primary key
name String Not null Name of contact
function String Function
email String Not null Email address

Table 9: Database table: mail_contact

The database model is illustrated below:

53
Figure 7: Database model

54
OJB To ease communication with the database, an object/relational mapping
tool is used. Such a tool allows committing the actual content of a Java Bean eas-
ily into the according database table and vice versa getting data out of the table
into the Java Bean transparently. The properties of the Java Bean correspond with
the attributes of the database table.

O/R mapping tools have some great advantages:

• All needed SQL-queries are generated by the tool. Therefore, the program-
mer is discharged of testing SQL-statements which were written. This as-
pect decreases the number of test runs and heightens the stability of the
product.

• The first project with a mapping tool needs some time to work in, but after
that time every software development cycle is accelerated.

• You are getting independent from the used database. Many O/R mapping
tools support varying databases. So it is possible to migrate to another data-
base without changing any code, only the mapping tool has to be reconfig-
ured.

One disadvantage of OJB is the reduced performance because only the own SQL-
code can be optimized to the used database. This loss of performance can be
compensated by so called proxy-classes. Database access is only executed if data
is actually needed. For example, a Java-collection is filled with proxy-classes and
only filled with data if the corresponding Java Bean is accessed with a get-method.

There exist many O/R-tools, for OSWP OJB (ObJect RelationalBridge) [Apaa]
was chosen. OJB is open source and programmed in Java.
There are four different APIs which can be used. OTM (Object Transaction Man-
ager), ODMG (Object Data Management Group) and JDO (Java Data Objects)
are all based on the PersistenceBroker kernel API. This is the most basic API and
provides low level access to the database. It is used for OSWP. It follows a short
introduction how OJB is used in OSWP.

The required parts for using OJB are listed below:

• Database tables that store all relevant data.

55
• JavaBeans accessed by the application corresponding to each database table.
These beans must provide get- and set-methods for each member variable
which accord to the database table attributes.

• OJB needs to know which bean and database table corresponds together.
This information has to be defined in a XML-file called repository.xml.

Figure 8: Connection of OJB and Java Beans

56
XDoclet The additional expenses which result in creating and maintaining the
repository.xml can be annoying since every change in the database also has to be
applied in the JavaBeans and the repository.xml. The OJB website proposes five
different approaches to automate some of these steps which include:

• Forward engineering from XMI

• Forward engineering from Torque

• Forward engineering from the repository.xml

• Reverse engineering from database

• XDoclet transformation from Java-code

The first three approaches generate the required Java-code, database scheme and,
in case of the first two, the repository.xml out of defined XML-files as well. They
are recommended if you begin a project from scratch having a large number of
persistent classes, because you are not bounded to any database restrictions yet.
By using reverse engineering from database the Java-code and the repository.xml
are generated out of it. Tools such as Druid or the Impart Eclipse Plug-in for OJB
take over this task [Apaa].

For OSWP the XDoclet transformation from Java-code was opted [Sou05]. By
adding meta data attributes to the Java-beans, like database specifications, the
XDoclet code generation engine parses the source files and creates the reposi-
tory.xml and the database scheme automatically. These meta data begins with
@ojb and has to include all necessary information such as table name, field name,
database restrictions (e.g. length) and OJB-internal options (e.g. auto-retrieve,
auto-update, auto-delete). The used meta data attributes are listed below:

Class/table definition: Each Java Bean represents a database table. This infor-
mation has to be inserted at the beginning of the class.

Example:

/** @ojb.class
* table="mail_smtpaccount" */
public class SMTPAccount { ...

57
Member variable/attribute definition: For each database attribute an equiva-
lent member variable must exist in the Java Bean.

Examples:

/** @ojb.field
* length="255" */
String username;
/** @ojb:field
* conversion=
"info.oswp.ojb.converter.Calendar2SqlTimestampFieldConversion"
* jdbc-type="TIMESTAMP" */
Calendar sentDate;

Reference/foreign key definition: Getting references via the get-method is very

simple. OJB fills the needed reference when it is accessed. Two entries are
needed: One for the database field which holds the foreign key, the second for
the object reference.

Example:

/** @ojb.field */
Integer userId;
/** @ojb.reference
* element-class-ref="info.oswp.model.User"
* auto-retrieve="true"
* auto-update="false"
* foreignkey="userId" */
User user;

58
Many-to-many relations definition: Such relations are very comfortable to
handle, as the many-to-many table does not have to be accessed directly. Just
by calling the get-method you gain a collection filled with the corresponding ob-
jects of the other table.

Example:

/** @ojb.collection element-class-ref="info.oswp.model.User"

* auto-retrieve="true"
* auto-update="false"
* indirection-table="mail_mailuser"
* foreignkey="emailid"
* remote-foreignkey="userid" */
java.util.Collection colUsers;

59
 Figure 9: XDoclet engine

The created repository.xml is ready to use, but the database scheme has to be trans-
formed into a database-SQL-script to create the required database tables. This
script is generated by Torque [Apad] out of the database scheme created by the
XDoclet code generation engine and can be executed to the database.

60
7.2.3 Presentation layer Struts/Tiles
Like any web-application which is implemented in Java, the presentation layer
contains the dynamic web pages called JSPs (JavaServerPages) and the logic be-
hind is made up of Java-Servlets and JavaBeans. In small projects it is no problem
to code the workflow without a planned structure. But the bigger a project grows,
the more it is essential to implement a central and standardized control of all re-
quests and responses.
The open-source framework Struts was used to ease implementing the GUI of
OSWP [Apab].

Some of the most important improvements of Struts are:

• Break-up of dialogues and logic: When changing logic you do not need
to adapt the dialogues as well. That leads to improved clarity and mainte-
nance. Furthermore, multiple usage of the same logic for different dialogues
becomes possible.

• Central control: By implementing the application flow directly into the busi-
ness logic, changing of sequences gets difficult. For this reason, a central
point for controlling of all application flows would be beneficial.

• Internationalisation: This feature is part of Struts and very ease to use. You
just have to manage the appropriate language text files.

• Validation of forms is also shipped out with Struts as a standard feature.

The typical workflow is described as follows: The client requests a specific page
which has to be defined as an action mapping. If available, the referring action
class is executed which contains the logic for the application flow and calls the
corresponding JSP (this information is specified in the tiles-forward). A response
is sent to the client. The data which is shown to, created and modified by the user
via the JSPs is stored in form beans by the according action class.

61
 Figure 10: Structure of presentation layer using Struts

Struts is configured with XML-files. Global configurations regarding the web

server are defined in the file web.xml. Struts itself use form beans, action map-
pings, exceptions and message resources which are configured in a XML-file
called struts-config.xml. Supplementary, Tiles is also used in OSWP [Apac]. Tiles
is a Struts-feature which allows assembling dialogue pages from several JSPs (so
called tiles). These tiles can be reused in another assembly, thus making mainte-
nance easier. The Tiles definition is configured in a XML-file called tiles-def.xml.

The two most important configurations in the struts-config.xml are explained in

the following. For each form bean a corresponding Java-class has to be created
which stores all data in its member variables. As in the example shown below, the
name is used for accessing the java-class by the JSPs and the action classes.

Example for a form bean:

<form-beans>

62
 <form-bean name=
"emailForm" type="info.oswp.oswpmail.web.action.EmailForm"/>
</form-beans>

Each request URI has to be mapped to a specified action class which contains the
particular application flow. In addition, forwards can be defined. If any forward
is called from the action class, the forward path is looked up in the Tiles definition.

Example for an action mapping:

<action path="/Sendemail"
type="info.oswp.oswpmail.web.action.SendemailAction"
name="emailForm" scope="session"
attribute="form" parameter="method">
<forward name="send" redirect="false"
path=".view.oswpmail.sendemail.send"/>
<forward name="success" redirect="false"
path=".view.oswpmail.sendemail.success"/>
<forward name="failure" redirect="false"
path=".view.oswpmail.sendemail.failure"/>
</action>

Every forward of an action mapping must lead to specified JSPs, defined in the
tiles-def.xml. As shown below, the name corresponds with the forward-path of
the action mapping. The example extends another defined tile and adds one page.

Example for a Tiles definition:

<definition name=".view.oswpmail.sendemail.send"
extends=".biglist.layout">
<put name="title" value="OSWP - open science work place"/>
<put name="centerbox_title" value="Compose Email"/>
<put name="centerbox_content"

63
 value="/WEB-INF/jsp/oswpmail/sendemail/compose.jsp"/>
</definition>

Configuring the struts-config.xml is very comfortable by using the StrutsConsole

[Hol05]. This tool can be employed stand-alone or as Eclipse-plug-in, for exam-
ple [ecl].

Figure 11: Screenshot of Struts Console

7.2.4 Email systems

There are several components which are needed in an email system.

• User: The user of the mail-system who sends and / or receives emails

• Mail User Agent (MUA): The interface between the user and the mail-
system.

• Message Store (MS): All messages have to be stored somewhere. The MS

acts as the mail-archive in this issue.

64
 • Message Transfer Agent (MTA): These are individual components of the
Message Transfer System and are responsible for the actual transmission of
messages.
• Message Transfer System (MTS): The MTS is the collectivity of all MTAs
and their connections.

Message transmissions are handled by these components at which the user creates
the message through his MUA. Afterwards, the MUA transfers the message to the
MTA. These agents are responsible for transmitting the message to its recipient(s).
This happens either directly if the recipient is in the same network as the sender, or
via store-and-forward delivered to the recipient of the message. After sending, the
recipients MTA retrieves the email and passes it to the recipients MUA [Gal04].

Now the protocols for sending and retrieving emails which were used in the
OSWP-implementation are described briefly.

SMTP SMTP stands for Simple Mail Transfer Protocol and manages the trans-
mission of emails in computer networks. It belongs to the TCP/IP protocol-family.
More precisely, SMTP is a protocol of the application layer of the TCP/IP model
[Uws].

Figure 12: TCP/IP model layers

SMTP is used to send messages from a mail client to a specified mail server but
not to retrieve them from the mail server. This is why you need to specify both

65
the POP or IMAP server and the SMTP server when you configure your email
application. Other SMTP-servers can be used as interstation to deliver emails to
its final destination.

The SMTP-server usually uses the port 25 as defined by the IANA (Internet As-
signed Numbers Authority) [Ian].

A typical SMTP session is shown below:

Figure 13: SMTP session example

SMTP is a really simple protocol. You can send emails from command line just
by using telnet [Web], for example. Sender and recipient are arbitrary, even the
addresses in the MAIL FROM and RCPT TO can differ from the addresses in the
To: and From:-fields of the mail header. In 1982, when SMTP was defined in
RFC821 [IETb], reliability was much more important than today because of the
little amount of hosts. In addition, the connections were slow and unstable. Every
mail server was an open relay. An open relay is a SMTP email server that does not
prohibit third party users to relay email messages. It is easy for any user to misuse
these mail servers to spam others, for example. Other expressions for open relay
are spam relay, third-party relay or insecure relay.
To prevent spammers from flooding other mailboxes, an extension to the SMTP-

66
protocol named ESMTP (Extended SMTP) was introduced. One important en-
hancement was the implementation of authentication on the mail server with user-
name and password. Usually, all authenticated users who used the ESMTP-mail
server are documented in a log file [Wikd].

POP3 Post Office Protocol Version 3 (POP3) is a standard protocol which is

used for retrieving emails from a mail server. Like SMTP, POP3 is also part of the
application layer from the TCP/IP protocol-family and is specified in RFC1939
[IETa]. POP3-sessions usually use the port 110 as defined by the IANA (Internet
Assigned Numbers Authority) [Ian].
POP3 does not need a constantly established connection to the mail server. After
mail retrieval the connection is closed since it was designed for dial-up connec-
tions. The protocol allows only limited features such as retrieval and deletion of
emails on the mail server. Additional features such as hierarchic folder manage-
ment on the mail server, pre-selection of emails etc. are not implemented. There-
fore, the protocol IMAP was defined [Was]. Most POP3-servers at least support
the leave on server-option. This feature allows using one advantage of IMAP in
a way: To access the mails from different locations. However, POP3 always re-
trieves the whole message, not only the header like IMAP when checking for new
mails.
Another problem is arising with POP3 while retrieving emails from the mail
server: Since POP3 does not support getting information about whether a mes-
sage was downloaded already or not, like IMAP does, the client has to manage
which emails have to be downloaded if the leave on server-option is used. POP3
commands relate to each message on the mail server to a unique number adminis-
trated by the mail server. Clients cannot rely on this unique number, because if a
message is deleted on the server, the numbers may change. The server addresses
the messages from one to the amount of mails without holes in the enumeration,
and therefore this unique number is useless for checking if the message is already
downloaded or not.
In my POP3-client implementation I used the following alternative:
In nearly every mail-header a unique Message-ID is included. This ID can be
fetched without retrieving the whole message. All IDs of the downloaded mes-
sages are stored in the database and during checking for new mails, the client
compares every mail-ID on the server with the IDs in the database. The email is
only retrieved if the ID is not stored in the database of course.

67
There are several POP3-server available, some of them are:
• Windows: Usually the POP3-server is integrated in the mail server-package
installed on the server (e.g. Microsoft Exchange)
• Unix: courier-pop, cyrus-pop3d, ipopd, popa3d, qpop3d (part of qmail),
qpopper, ipop3d
A typical POP3-session is listed below:

Figure 14: POP3 session example

The disadvantage of transmitting the password in plaintext can be avoided by us-

ing APOP (Authenticated POP). At the beginning of the session the mail-server
sends a timestamp and the client calculates a MD5-hash from this timestamp and
the password. This hash is sent back to the server where it is compared with the
calculation result of the server. If they are equal, the login procedure is successful.

68
Usually, every mail server includes a SMTP- and a POP3-server which handle
mail-traffic as shown in the following illustration:

Figure 15: Mail traffic overview

MIME In the early days of the Internet, an email consisted of readable, English
text messages. In time, the RFC822 standard (text messages) [IETc] got inade-
quate and several extensions were defined because the RFC 822 cannot encode
the following data [Gal04]:

• Binary data (e.g. pictures, videos, audio files, ...)

• Messages including non standard characters such as umlauts in non English

languages (e.g. German or French)

• Messages in non Latin languages (e.g. Russian) or even languages with no

letter-like alphabets (e.g. Chinese or Japanese)

To find a remedy, MIME was defined. MIME stands for Multi-purpose Inter-
net Mail Extensions. Nowadays, Multimedia Internet Message Extensions also
is usual. It is not a protocol, but it rather defines the content which is sent. It

69
sets the standard for the format, the structure and builds up of an email and other
Internet-messages. MIME allows exchanging information about the type of the
transmitted data (content-type) between sender and recipient. Simultaneously in-
formation about the encoding of the message (content-transfer-encoding) is also
transposed. There are several options to encode non-ASCII messages. Non-text
elements are usually base64-encoded, non-ASCII characters are often encoded by
using quoted/printable. MIME messages can contain multiple body parts which
are separated by boundaries [Wikc].

Example for a multi part MIME message:

Figure 16: MIME message example

7.2.5 Mail User Agent - JavaMail API

The JavaMail API is an optional package and standard extension respectively for
reading, creating and sending of emails. You can implement MUA (Mail User
Agent) programs analogously to Mozilla Thunderbird, Outlook or Eudora, for
example [Sun05b].

70
The purpose of the JavaMail API is not to transport, deliver or redirect the mes-
sages like sending email in UNIX or other MTAs, but rather to provide protocol-
independent access to send and retrieve messages. To communicate with a mail-
server, a so called provider for the required protocol is needed. There are provider-
packages available from Sun which contain the most common protocols such as
POP, SMTP, IMAP or MIME. JavaMail allocates many useful methods to imple-
ment the features which are needed when implementing a mail-application.
The implementation structure of the email business logic is illustrated below:

Figure 17: Structure of business logic

7.2.6 Message store

Since every mail-system needs a message store, this part was also implemented
for OSWP. As shown in the database-layer chapter, all emails have references in
the corresponding email table in the database. The emails itself are stored on the
file system on the application server. The main reason not to store the emails in
the database was not to exceed the size of the database, because attachments can

71
be very large. Therefore, a folder on the application server has to be configured to
store the emails. Each email is saved in a separate file with the extension ’.eml’
which has been widely accepted for storing emails. Most of the email clients can
open this file type.

Filename conventions were defined as described below:

• Emails sent through OSWP: Internal - Date - Unique Message-ID.eml

Example: Internal - 06.06.2005 - 12314427.1118060117566.Java-

Mail.rneur@robert.eml

• Emails retrieved into OSWP: Date - Unique Message-ID.eml

Example: 30.05.2004 - 20675.1096564058@www65.gmx.net.eml

• Emails assigned to a project in OSWP: Project name Project ID - Date -

Unique Message-ID.eml

Example: Project 1[169] - 28.02.2005 - 7779612.1109615551847.Java-

Mail.rneur@robert.eml

7.3 Implemented part

7.3.1 Overall Configuration
First of all, some important configurations have to be made. The system-wide
mail options are accessible via the admin-link. All mails are stored in a specified
folder which can be edited per Files. For each email which is sent or downloaded,
a new eml-file and an according entry in the database is created.
The internal SMTP-account can be configured by clicking on Mail. Mandatory
fields are the host, the address of the sender, the account name and the password.
The option Blind copy for recipients makes two forms of sending an email pos-
sible: If selected, all messages are sent to all recipients in blind copy and use the
sender as recipient in the To-field. Otherwise all recipients are simply added in
the To-field of the message.

72
 Figure 18: Screenshot - General mail options

7.3.2 User options

Each user is able to configure his own settings, including SMTP- and POP3-
accounts, signatures and mail-filters. Also the global contact list is editable by
all users.

SMTP- and POP3-accounts Both account types can be created, edited and
deleted in the same way. They need an account name, a server name, a user-
name and a password. Supplementary, for the SMTP-account a send address has
to be specified. An internal SMTP account is also available. The user can choose
whether the mails are deleted from the POP3-account after retrieval or not.

73
 Figure 19: Screenshot - Edit SMTP account / POP3 account

Signatures Signatures are used for adding information, such as the name or the
contact information of the sender, at the end of a message. Every user can manage
several signatures and select one when sending an email.

Contacts Not all regular recipients who receive emails through the portal are
registered as user in the system. This contact list allows to choose comfortably
recipients who are not regular project members or OSWP-users. The list is global
and every user can create new and edit existing contacts.

Mail filters These filters allow automated assignment of retrieved mails to projects.
Three filter types are available, including subject, sender and text. If any of the
specified filters apply to a downloaded message, it is assigned to the specified
project.

74
 Figure 20: Screenshot - List of all filters

7.3.3 Send mail

This form allows users to send emails either via the internal or a user-specific
configured SMTP-account.
Four types of recipients are possible which include:

• Contacts: All available contacts which were created can be selected.

• Projects: All projects where the user is allocated can be selected. Mails are
automatically assigned to any selected project.

• Users: All available users can be selected.

• Additional recipients: Any valid email addresses are possible, they have to
be separated by commas.

Beneath the entered subject and written text it is possible to add self-defined sig-
natures. Files can be attached by browsing to its location and simply click on add
selected. The file names of already attached files are shown below.

75
 Figure 21: Screenshot - Compose email

To send the message, you just have to click on Send. Afterwards, a dialogue dis-
plays either a success or a detailed error message.

76
 Figure 22: Screenshot - Feedback after sending email

7.3.4 Email overview

The illustration below shows a typical email-overview, in this case of a POP3-
account. Emails can be shown, replied, deleted or assigned to a project via such a
page. Emails with an attachment have a paperclip-icon.

Figure 23: Screenshot - Email overview of a POP3 account

7.3.5 Email info

By clicking on an email, all email details are shown. Previous mail and Next
mail allow comfortable paging through all mails in the folder. Attachments can

77
be saved to disk per "Save attachment".

Figure 24: Screenshot - Show email

7.3.6 Own POP3-accounts

Every user is able to configure several POP3-accounts and retrieve mails from the
chosen account. By clicking on Check mails all new messages are downloaded.
Messages which have already been downloaded are ignored. This feature allows
the user to manage his personal or work related emails. Even more important,
the user is able to assign any of his messages explicitly to a project extending the
projects email repository.

7.3.7 Sent mails

This link leads to an overview of all mails which were sent through this web client
by the user.

7.3.8 Project mails

Every user can be assigned to different projects. To view the emails of a project,
the user has to select the desired project and then he gets to the designated email-
overview. The emails which are assigned to the projects can present a valuable

78
knowledge base for the according project. Email discussions held via this portal
according to a project can be traced and accessed.

7.4 Usability evaluation

To enhance the usability of the implemented part, I conducted a small-scaled us-
ability test with five test persons. These test persons were mostly students, but
their branches of study were well diversified. They are studying sociology, busi-
ness informatics, biology, journalism and also an electrical engineer who now
works as a hardware designer was among these test persons.

I defined the following tasks which the test user had to perform. They were de-
fined in form of scenarios like those described in a previous chapter. The required
data for logging in and creating accounts and also the needed passwords were
given to the test users prior to the evaluation.

After a short introduction, the test users had to complete two scenarios:

• Scenario 1: Please login and create a new SMTP-account and a new sig-
nature. Then compose a new email, attach some files, choose the created
signature and send the message to a project.

• Scenario 2: After the email is successfully sent, create a new POP3-account

and retrieve the messages from this account. Open an email with an attach-
ment and store the attachment to the local computer. Afterwards, assign this
email to a project.

The duration of each scenario should not extend ten minutes. I used the Thinking
Aloud Method during the evaluation and I noted the comments of the test users.
Afterwards, the test users had to fill in a prepared questionnaire by grading ques-
tions from 1 to 5. 1 was the best grade (very good, very easy, etc.) and 5 the worst
(very bad, very difficult, etc.).

The questionnaire and its results is listed below:

79
 Question Count best grade Average value
How clearly arranged and in- 3 1,4
tuitive are the features?
Is the navigational concept 4 1,2
well situated?
Is the feedback of the portal 3 1,6
adequate?
How do you like the design? 3 1,6
Table 10: Results of questionnaire

I categorised the usability problems which were found during the evaluation test
and during a meeting with Dr. Alexander Schatten. The problems were fixed
afterwards:

7.4.1 Critical usability problems

• Selection of the recipients (contacts, projects and users) was first realised
with check boxes. The list of the recipients was very long, therefore the
check boxes were replaced by a multiple select. A short explanation how
to select multiple recipients is displayed on the web page (For example:
holding the Strg/Ctrl key during selection in Windows).
• While composing a message, it was not obvious at first, how many attach-
ments were already added to the message. Now you can see a list of the
attached files above the send button.
• I added links to the next and the previous message in the email overview so
that users can skim through the emails easier.

7.4.2 Minor usability problems

• The display of the emails was not very satisfying for the test users. I con-
verted and formatted the body of the email to a more appealing look.
• Most of the test users complained about a missing icon which displays
whether the message has attachments or not, so I added this feature.
• At first, the email was accessible only per icon in the email overview. Now
you can also click on the subject to open an email.

80
7.4.3 Cosmetic usability problems
• Some translations were missing or not correct.

7.5 Future outlook

The current implemented features of the email based communication part of OSWP
can of course be extended. Some interesting new features could be:

7.5.1 IMAP
Receiving emails is only possible via the POP3-protocol by now, which lacks
some valuable feature provided by IMAP (Internet Message Access Protocol)
such as central archiving of the emails on the IMAP-server and therefore re-
duction of local space needed for the downloaded messages, conjoint usage of
mailboxes by several users, server-side sorting and searching, etc. In contrast to
POP3-servers, the messages remain on the IMAP-server and are only transferred
to the client if actually needed. Implementing an IMAP-client besides the POP3-
client would further improve the OSWP portal [Wikb].

7.5.2 Visualisation of email-threads

To enhance the overview of the project-related email discussions in OSWP, these
threads could be visualised similar to a discussion forum. By seeing at a glance
which statements were answered by which one and in which order, this form of
project communication would be greatly enhanced.

7.5.3 Full text search of emails

As already mentioned, email based communication can create valuable knowl-
edge over time. Searching for needed information can be time-consuming. By
providing a full text search in all emails stored in OSWP, searching for informa-
tion would be done much faster.

7.5.4 Virtual folders defined by extended email filters

Now it is possible to create email filters to assign emails automatically to a project
by defined rules. By extending such filters to define criteria to display emails in a
specified physical non-existent folder, categorising emails for personal purposes

81
would be enabled. This feature would be comparable to search methods which
can be managed and the results viewed anytime without conducting a search.

7.6 Seven theses

The great importance of communication as part of project management is
often underestimated. Many project members, the project manager included,
are often not aware of the matter of fact as follows: Defective communication
within the project team or between the project team and other stakeholders of the
project is the main cause of many problems which arise during a project. The
required communication network to accomplish coordination between the project
stakeholders ensuring successful time scheduling, resource planning, etc. should
satisfy exchange of information, exchange of experience and in addition improve
mutual assistance.

Distributed and collaborative project management replaces conventional single-

location and stand-alone project management approaches making new ways
of collaboration necessary. Because of today’s business globalisation, funda-
mentals of project management are changing. Instead of having all project mem-
bers at one site, project teams are possibly scattered all over the world nowadays,
especially when it comes to software development.

The Internet allows new forms of direct communication which are very effi-
cient and applicable for many different tasks. Mankind finally arrived in the
Information Age and the Internet with its communication channels such as email,
chat, telephone/video conferences etc. brings people closer together than they
ever were before. These communication channels can be utilised for many tasks
improving collaboration within project teams.

Emails with its advantages and disadvantages as a communication channel

are revolutionising social interactions and are influencing people on both
individual and organisational level. Due to the popularity of emails nearly
everybody who has access to the Internet sends and receives emails. This com-
fortable and quick way of exchanging information more and more displaces con-
ventional forms of communication e.g. with the effect of decreasing social inter-
actions between the dialogue partners. These aspects are discussed in detail in this
thesis.

82
If utilised correctly, emails can be a valuable addition to knowledge man-
agement by creating new knowledge during email discussions. To also ben-
efit from communication afterwards, the aquired information somehow has to be
stored and structured. Including new built knowledge created during email dis-
cussions into a knowledge base can represent a great value for companies, univer-
sities, etc. This knowledge development process via email and, in addition, two
examples for this kind of knowledge development are discussed.

Web-based software development requires even more detailed planning than

other software developments because of its interdisciplinary characteristics,
difficult cost planning and its limited potentials regarding usability like navigation,
limited bandwidth and feedback options. The interdisciplinary characteristics of
web projects lead to extended communication efforts between web designers, IT-
specialists, business economists, editors and other participated stakeholders.

Nowadays, open source products represent a high valuable alternative for

software development efforts such as source code libraries, development frame-
works or whole software products like application servers, databases or develop-
ment environments. For this thesis, many of these open source products were
deployed, for example, the Java frameworks OJB [Apaa] and Struts [Apab], the
development environment Eclipse [ecl], the application server JBoss [JBo] and
the database PostgreSQL [Pos05].

This master thesis was elaborated, implemented and finally written between au-
tumn 2004 and summer 2005.

83
References
[Ank99] Patti Anklam: Technical communications as knowledge management:
Evolution of a profession. In: ACM Proceedings of the 17th annual
international conference on Computer documentation (1999), p. 36–
44

[Apaa] Apache: The Apache DB project: ObJectRelationalBridge OJB.

http://db.apache.org/ojb. – last visited 15.07.2005

[Apab] Apache: Struts. http://struts.apache.org. – last visited

10.06.2005

[Apac] Apache: Tiles guide. http://struts.apache.org/

userGuide/dev_tiles.html. – last visited 03.04.2005

[Apad] Apache: What is Torque? http://db.apache.org/torque. –

last visited 05.07.2005

[AS04] Alexander Schatten, Marian Schedenig, Amin Andjomshoa: Open

Science Workplace: Building an Web-Based Open Source Tool to
Enhance Project Management, Monitoring and Collaboration in
Scientific Projects. http://www.oswp.info/downloads/
documentation/oswp_userdoc.pdf. Version: 2004. – last
visited 20.07.2005

[Bae93] Ronald M. Baeker: Groupware and computer-supported cooperative

work. Morgan Kaufmann Publishers, 1993

[Bur95] Manfred Burghardt: Einführung in Projektmanagement. Publicis

MCD Verlag, 1995

[col05] Verteiltes kooperatives Entwickeln. http://www.informatik.

uni-oldenburg.de/~iug04/vke/index.html.
Version: Website, 2005

[Did04] Didac: Grundlagen des Projektmanagements. http://www.

didac-pro.de. Version: Website, 2004. – last visited 27.06.2005

[ecl] eclipse.org. http://www.eclipse.org/. – last visited

28.07.2005

84
[FC03] Fang Chen, Nicholas C. Romano Jr., Jay F. Nunamaker Jr., Robert O.
Briggs: A collaborative project management architecture. In: IEEE
Proceedings of the 36th Hawaii International conference on system
sciences (2003), p. 12 pp.

[Fre99] Hartmut Frey: E-Mail: Revolution im Unternehmen. Hermann

Luchterhand Verlag GmbH, 1999

[Gal04] Galileocomputing: Java ist auch eine Insel. http:

//www.galileocomputing.de/openbook/javainsel4.
Version: Website, 2004. – last visited 10.06.2005

[GP04] Gerold Patzak, Günter Rattay: Projektmanagement. 4. Auflage. Linde

Verlag Wien, 2004

[Hee93] Franz-Josef Heeg: Projektmanagement. 2. Auflage. Carl Hanser

Verlag, 1993

[Hol05] James Holmes: Struts console. http://www.jamesholmes.

com/struts/console. Version: 2005. – last visited 04.05.2005

[Ian] Iana: Internet assigned numbers authority. http://www.iana.

org. – last visited 02.07.2005

[Ibi04] Ibim: Warum Projektmanagement? http://www.ibim.de/

projekt/1-1.htm. Version: 2004. – last visited 27.06.2005

[IETa] IETF: Post Office Protocol Version 3. http://www.ietf.org/

rfc/rfc1939.txt. – last visited 05.07.2005

[IETb] IETF: Simple Mail Transfer Protocol. http://www.ietf.org/

rfc/rfc821.txt. – last visited 05.07.2005

[IETc] IETF: Standard for the format of ARPA internet text messages. http:
//www.ietf.org/rfc/rfc822.txt. – last visited 08.07.2005

[JA00] Josef Altmann, Gustav Pomberger: Cooperative Software Devel-

opment: Concepts, Model and Tools / C. Doppler Laboratory for
Software Engineering. Johannes Kepler University Linz, 2000. –
Forschungsbericht

85
[JBo] JBoss: JBoss application server. http://www.jboss.org. – last
visited 02.07.2005

[JMH02] Jörg M. Haake, José A. Pino: Groupware: Design, implementation

and use. Springer Verlag Berlin Heidelberg, 2002

[Kin97] Roger L. King: Learning how to use the Internet and Web resources.
In: IEEE Computer applications in Power, Volume 10, Issue 2 (1997),
p. 20–25

[Klö99] Franz Klöfer: Erfolgreich durch interne Kommunikation. Hermann

Luchterhand Verlag GmbH, 1999

[Laz01] Jonathan Lazar: User centered web development. Jones and Bartlett
Publishers International, 2001

[LEO] LEO: LEO English-German Dictionary. http://dict.leo.org.

– last visited 10.08.2005

[Leo98] David C. Leonard: Electronic evolution: From technical communica-

tion to knowledge management. In: IEEE Proceedings. International
Professional Communication Conference, IPCC 98. Volume 2 (1998),
p. 9–20. – Cambridge, Massachusetts

[Lic04] Sharman Lichtenstein: Knowledge development and creation in email.

In: IEEE Proceedings of the 37th Annual Hawaii International Con-
ference on System Sciences (2004), p. 245–254

[LyX] LyX: LyX - The Document Processor. http://www.lyx.org/. –

last visited 30.07.2005

[MCB02] Marco C. Bettoni, Robert Ottiger, Rolf Todesco, Kurt Zwimpfer: Indi-
vidual knowledge management with MailTack. In: IEEE Proceedings
of 13th International Workshop on Database and Expert Systems Ap-
plications (Sep. 2-6. 2002), p. 157–161. – Aix-en-Provence, France

[McG00] Lynn McGee: Communication channels used by technical writers

throughout the documentation process. In: IEEE Transactions on pro-
fessional communication Volume 43, Issue 1, March 2000 (2000), p.
35–50

86
[MD01] Michael Dain, Jack Brzezinski: MEME: An adaptive email-based
information sharing system for educational institutions. In: IEEE Pro-
ceedings. 12th International Workshop on Database and Expert Sys-
tems Applications (2001), p. 449–453

[Mea02] J. Meads: Laid-off usability engineer, or why we don’t get no respect.

In: ACM Press. Interactions archive, Volume 9, Issue 3 (2002), p. 13–
16

[MM02] Martina Manhartsberger, Sabine Musil: Web Usability. Galileo Press

GmbH, 2002

[NCRJ02] Nicholas C. Romano Jr., Fang Chen, Jay F. Nunamaker Jr.: Collabo-
rative project management software. In: IEEE HICSS. Proceedings of
the 35th Annual Hawaii International Conference on System Sciences
(2002), p. 233 – 242

[Neg95] Nicholas Negroponte: Being digital. Vintage Books, 1995

[Niea] Jakob Nielsen: Usability 101: Introduction to Usability. http://

www.useit.com/alertbox/20030825.html. – last visited
18.02.2005

[Nieb] Jakob Nielsen: Usability 101: Severity Ratings for Usability

Problems. http://www.useit.com/papers/heuristic/
severityrating.html. – last visited 18.02.2005

[Nie93] Jakob Nielsen: Usability Engineering. Academic Press, 1993

[Nie00] Jakob Nielsen: Designing Web Usability. 2nd edition. Boston Acad-
emic Press, 2000

[OSW05] OSWP: Open Science Workplace. http://www.oswp.info.

Version: 2005. – last visited 20.07.2005

[PCP04] Parag C. Pendharkar, Karl Young: The development of a construct

for measuring an individual’s perceptions of email as a medium for
electronic communication in organizations. In: IEEE Transactions on
professional communication, Volume 47 (2004), p. 130–142

87
[PL00] Paul Layzell, O. Pearl Brereton, Andrew French: Supporting collab-
oration in distributed software engineering teams. In: IEEE Proceed-
ings. Seventh Asia-Pacific Software Engineering Conference APSEC
2000 (Dec. 5-8 2000), p. 38–45. – Singapore
[Pos05] PostgreSQL: PostgreSQL. http://www.postgresql.org.
Version: 2005. – last visited 02.07.2005
[Sch98] Celia Schahczenski: Experiment substituting in-class discussions with
email discussions. In: IEEE FIE ’98. 28th Annual Frontiers in Educa-
tion Conference, Volume 1 (1998), p. 136–140. – Tempe, AZ
[Sch00] Michael Peter Schmidt: Knowledge communities. Addison-Wesley
Verlag, 2000
[Sou05] Sourceforge: What is XDoclet? http://xdoclet.
sourceforge.net. Version: 2005. – last visited 05.07.2005
[Sto04] Robert Stoyan: Management von Webprojekten. Springer Verlag
Berlin Heidelberg, 2004
[Sun05a] Sun: Java 2 Platform, Enterprise Edition (J2EE) Overview. http:
//java.sun.com/j2ee/overview.html. Version: 2005. –
last visited 20.07.2005
[Sun05b] Sun: Java Mail API documentation. http://java.sun.
com/products/javamail/javadocs/index.html.
Version: 2005. – last visited 10.06.2005
[TCF98] TCForum: Building Usability into Your Development Process.
http://www.tc-forum.org/topichig/hl04wher.htm.
Version: 1998. – last visited 04.03.2005
[Uws] Uwsg: ISO OSI 7 layer model forced with TCP/IP.
http://www.uwsg.iu.edu/usail/network/nfs/
network_layers.html. – last visited 13.07.2005
[Was] University of Washington: The IMAP connection. http://www.
imap.org. – last visited 14.07.2005
[Web] Webopedia: What is telnet? http://www.webopedia.com/
TERM/T/Telnet.html. – last visited 17.07.2005

88
[Wika] Wikipedia: E-Mail. http://de.wikipedia.org/wiki/
E-Mail. – last visited 27.07.2005

[Wikb] Wikipedia: Internet message access protocol. http://de.

wikipedia.org/wiki/Imap. – last visited 22.07.2005

[Wikc] Wikipedia: Multipurpose Internet Mail Extensions. http:

//de.wikipedia.org/wiki/Multipurpose_Internet_
Mail_Extensions. – last visited 11.07.2005

[Wikd] Wikipedia: Simple Mail Transfer Protocol. http://de.

wikipedia.org/wiki/SMTP. – last visited 21.07.2005

[Wike] Wikipedia: Webmail. http://de.wikipedia.org/wiki/

Webmail. – last visited 26.07.2005

[Wikf] Wikipedia: Webserver. http://de.wikipedia.org/wiki/

Webserver. – last visited 27.07.2005

89
List of Figures
1 Management cycle [Hee93] . . . . . . . . . . . . . . . . . . . . . 4
2 Knowledge creation process . . . . . . . . . . . . . . . . . . . . 31
3 Overlap of IT and design in web projects . . . . . . . . . . . . . . 34
4 System architecture of a web project . . . . . . . . . . . . . . . . 38
5 Feature-overview of the email module . . . . . . . . . . . . . . . 47
6 Overview and structure of the used components . . . . . . . . . . 48
7 Database model . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8 Connection of OJB and Java Beans . . . . . . . . . . . . . . . . . 56
9 XDoclet engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10 Structure of presentation layer using Struts . . . . . . . . . . . . . 62
11 Screenshot of Struts Console . . . . . . . . . . . . . . . . . . . . 64
12 TCP/IP model layers . . . . . . . . . . . . . . . . . . . . . . . . 65
13 SMTP session example . . . . . . . . . . . . . . . . . . . . . . . 66
14 POP3 session example . . . . . . . . . . . . . . . . . . . . . . . 68
15 Mail traffic overview . . . . . . . . . . . . . . . . . . . . . . . . 69
16 MIME message example . . . . . . . . . . . . . . . . . . . . . . 70
17 Structure of business logic . . . . . . . . . . . . . . . . . . . . . 71
18 Screenshot - General mail options . . . . . . . . . . . . . . . . . 73
19 Screenshot - Edit SMTP account / POP3 account . . . . . . . . . 74
20 Screenshot - List of all filters . . . . . . . . . . . . . . . . . . . . 75
21 Screenshot - Compose email . . . . . . . . . . . . . . . . . . . . 76
22 Screenshot - Feedback after sending email . . . . . . . . . . . . . 77
23 Screenshot - Email overview of a POP3 account . . . . . . . . . . 77
24 Screenshot - Show email . . . . . . . . . . . . . . . . . . . . . . 78

90
List of Tables
1 Success probability of web projects . . . . . . . . . . . . . . . . 36
2 Database table: mail_email . . . . . . . . . . . . . . . . . . . . . 50
3 Database table: mail_task . . . . . . . . . . . . . . . . . . . . . . 50
4 Database table: mail_mailuser . . . . . . . . . . . . . . . . . . . 51
5 Database table: mail_pop3account . . . . . . . . . . . . . . . . . 51
6 Database table: mail_smtpaccount . . . . . . . . . . . . . . . . . 52
7 Database table: mail_signature . . . . . . . . . . . . . . . . . . . 52
8 Database table: mail_filter . . . . . . . . . . . . . . . . . . . . . 53
9 Database table: mail_contact . . . . . . . . . . . . . . . . . . . . 53
10 Results of questionnaire . . . . . . . . . . . . . . . . . . . . . . . 80

91
Index
Abstract, ii
Acknowledgements, i
Advantages of e-mail, 17
Benefits of project management, 2
Chats, 16
Collaborated PM, 23
Communicational aspects, 8
Comp. supported comm. (CSC), 9
Conclusion, 82
Direct communication, 12
Direct communication channels, 14
Discussion forums, 16
Distributed PM, 23
Distributed PM: Advantages, 25
Distributed PM: Challenges, 23
Distributed PM: Difficulties, 25
Distributed PM: Reasons, 24
E-mail: individual influence, 21
E-mail: individual perception, 19
E-mail: organisational influence, 22
E-mail: social impact, 19
E-mails, 16
Eidesstattliche Erklärung, i
Goals of an information system, 7
Groupware systems: Classification, 26
Groupware systems: Communication, 28
Implementation, 45
JavaMail API, 70
Knowledge development, 29
92
Knowledge development cycle, 30
Knowledge development:Examples, 32
MailTack, 32
Means of project information, 6
Meetings, 14
MEME, 32
MIME, 69
OJB, 54
OSWP, 46
OSWP: Application server, 48
OSWP: Database layer, 49
OSWP: Database model, 53
OSWP: Database tables, 49
OSWP: E-mail systems, 64
OSWP: Future outlook, 81
OSWP: GUI, 72
OSWP: Needed components, 47
OSWP: New features, 46
OSWP: Presentation layer, 61
OSWP: Usability evaluation, 79
POP3, 67
PostgreSQL, 49
Project documentation, 12
Project goal, 46
Project Management, 1
Project related communication, 8
Project reporting, 11
SMTP, 65
Struts, 61
Tasks of PM - Controlling, 5
Tasks of PM - Organization and com-
munication, 6
Tasks of PM - Planning, 4
Tasks of PM - Team leadership, 5
Tasks of project management, 4
Telephone, 15
Telephone conferences, 14
The three C-s, 8
Trends caused by CSC, 10
Types of project related comm., 11

Usability evaluation, 43
Usability test methods, 44

Video conferences, 14

Web projects: Architecture, 38

Web projects: Characteristics, 35
Web projects: Definition, 34
Web projects: Expanse factors, 37
Web projects: Success factors, 36
Web projects: Usability, 41
Web usability, 40
Web usability: Categorisation, 42
Web-based software development, 34
Webmail, 40
Why project management?, 1
Workshops, 15

XDoclet, 57

Zusammenfassung, ii

93