Using the Internet in project management
Alistair D N Edwards
Department of Computer Science
University of York
York, England, YO1 5DD
phone: +44 1904 432775
fax: +44 1904 432767
email: alistair@minster.york.ac.uk
1. Summary
This paper presents some suggestions as to how best to make use of the Internet in running an international collaborative project.
| Top |
2. Introduction
TIDE and associated Telematics initiatives are concerned largely with the development of information technologies but it is easy to overlook the fact that information technology can have a vital role to play in the execution and management of projects within these initiatives. The requirements of the projects mean that workers collaborate between remote locations. Communication between them is essential and the Internet is primarily an excellent communication tool. This paper is written from the experience of a Tide project (Maths, TP1033, Weber, Bornschein et al., 1997) with the objective of helping future projects to make the most of the facilities that are available.
| Top |
3. Planning
The time to start considering the role of the Internet is long before the project is started, when the proposal and the Technical Annex are being written. If it is to be exploited then resources must be allocated to managing the network use. It might be tempting, in a desire to pare back financial demands, to not budget for network management, but that would be a false economy; the benefits from efficient use of network resources far outweigh any cost.
| Top |
4. Centralization
A central site is required to be the hub of all network use. With a Data Manager at that site responsible for maintenance, the data can be assured to be safe and unnecessary duplication can be avoided. Of course, the main danger of centralization of any resource is that loss of that site implies complete loss. The chosen site should therefore be one of high reliability with established support mechanisms (that is to say, ideally a computer centre). Downtime should be minimal and (it hopefully goes without saying) that the site should have an effective backup regime. The other requirement is that the site should have adequate network bandwidth.
| Top |
5. Email
Email has well known advantages as a means of communication - and some disadvantages. In conventional use, most email messages are person-to-person, but in a small collaborative project, broadcasting email can enhance communication by keeping all participants in touch with developments. A single address can be established such that an email sent to that address gets copied to all the participants. (See Appendix)
There is of course a danger that traffic can become overwhelming, that detailed mails that are of interest to only two or three people waste the time of the others. This can be alleviated by careful use of Subject: headings in the mails. A carefully worded title can quickly inform individuals whether that item is likely to be important to them.
One of the problems of email is that it is not always as reliable as may be hoped. Writers often assume that because a mail has been sent that it has been received - and read. This may not be the case, for a number of reasons. This is one reason why it can be a good idea to ensure that all mail broadcast to the group is archived on the central site. Any partner missing out on a thread of the correspondence can then consult the archive. It can also prove valuable in the case where there is a mis-understanding (not to say dispute) as to what has been said and agreed on within the correspondence.
An alternative or supplementary means of communication is the newsgroup. Groups might be set up for discussion of different topics (e.g. design of different aspects of the project). This mechanism did not seem necessary in the Maths project, which was quite small (five partners) but might be necessary in a larger consortium for which email traffic may become excessive.
| Top |
6. Management
Ideally one individual at the central site should be in charge of managing the data held there. Each project will evolve its own directory structures. There are likely to be separate directories for software (completed and under development), draft documents, finalized internal reports, deliverables, other publications.
The Data Manager and other project members should have different levels of access to the files. (See the Appendix for a discussion as to how to achieve this on Unix). Only the manager should have write access to all the files, other members should have only read access to most files.
There should be one directory which can be written into by all the partners into which they can deposit contributions by FTP. All other directories should be read-only for partners so that the Data Manager only can update them. In this way the manager maintains control and can keep the site tidy.
When a partner deposits a file in the incoming directory he or she should mail the Data Manager with the details (this is one instance where the broadcast address should not be used). The manager can then move the file to the appropriate directory, update the information about it and then broadcast the news to all partners.
Good use of file names can be most valuable. The extent to which this can be done depends on the naming restrictions on the host computer, the maximum length of a file name, whether it can contain punctuation or spaces and so on. Each directory should contain a 'read.me' file which contains an abstract of the files contained therein (See Figure 1).
$ls -l
-rw-r--r-- 1 project pgroup 1000 Mar 3 d1_1.0.rtf
-rw-r--r-- 1 project pgroup 1100 Apr 6 d1_1.1.rtf
-rw-r--r-- 1 project pgroup 1901 Apr 24 d1_final.rtf
-rw-r--r-- 1 project pgroup 12402 Jun 6 journal_1.0.rtf
-rw-r--r-- 1 project pgroup 520 Jun 6 read.me
$cat read.me
Contents of the directory 'drafts'
d1_1.0.rtf Draft version 1.0 of deliverable D1, written by
Poppleton 6/3/97.
d1_1.1.rtf Revised draft, version 1.1 of D1, incorporating
amendments from Paris and Berlin, 6/4/97.
d1_final.rtf Final draft of D1 with further additions from
Paris and minor corrections by Poppleton 24/4/97. See
'deliverables/D1.RTF' for the published version.
journal_1.0.rtf Draft of a journal paper by Poppleton,
posted for comment from other partners on 6/6/97.
read.me This file.
Figure 1. Contents of a typical (Unix) directory on the FTP site.
The Data Manager need not necessarily be the Lead Partner. This was not the case in the Maths project and it did not seem to cause any problems. The amount of work required of the Data Manager should not be under-estimated. At the height of the project, several files a day may be arriving on the FTP site and it is important that they are installed, logged and members notified quickly.
| Top |
7. Security
Most of the data will be confidential to the project (the exception is publicity material, see the section, Publicity). Access must be password-controlled. Of course the password should be changed frequently and shared by non-electronic means; a review meeting is the ideal opportunity.
Related to security is the question of data protection. The requirements will vary between countries and there are complex questions as to whether the legal requirements of one country can be applied to data held in another (see Rosenoer, 1997, for more details). The main message is that the Data Manager should take all reasonable steps to ensure that the data is at least protected and registered as required by local legislation.
| Top |
8. Formats
A universal problem of sharing electronic documents is the lack of standarization of formats. Documents require formatting information and will often contain 'non-standard' material such as mathematics and graphics. The main message is to chose one format that is adequate to your project's needs and to stick to it. Partners should be prevented from trying to 'slip in' a document in another format, however good their reasons.
Currently the two popular formats are Microsoft Word and Latex. If Word is to be used, then documents must be stored in Rich Text Format (RTF). This is the only format which is universal between different versions of Word and it does have the advantage that it encodes graphics as well as text. Users should still be aware though that RTF is not infallible, that a document may not look the same at different sites. The use of different national character sets is probably the main cause of this.
Latex is very powerful, but there may have to be some effort expended on ensuring that the Latex configurations are compatible at all sites. A document may be created at one site which assumes the presence of certain facilities that may not be available at another.
PostScript is another widely accessible format. This can be quite useful for dissemination of completed documents, but is not suitable for drafts that people need to edit.
| Top |
9. Code sharing
Many telematics projects involve the development of software. With different partners contributing different modules there is a need for code sharing. This might be achieved through the use of portable storage media (e.g. Zip discs), but they must be physically transported (by postal service or courier) and will perpetrate multiplication; there will be occasions when it is effectively impossible to know that the version of the software that one partner has is truly identical to that held by another.
Instead, FTP can be used to transfer software to the central site, from which all partners can obtain copies. The management procedures outlined above should be adhered to, but this way software can be distributed most efficiently. This can be most valuable during debugging and testing when it is possible for one partner to identify a bug and for the originating partner to have posted fixed code within hours.
| Top |
10. Publicity
One of the obligations of Tide project is dissemination. The World Wide Web is one valuable way of contributing to this. A home page should be set up - and maintained. This can give general information about the project that would be of interest to a general readership. The home page should include a list of publications, with those which are publicly available downloadable (either as HTML pages or downloadable documents in PostScript format). Individual partners may wish to maintain their own pages linked to the home page, in which their contributions are described. It is one of the features of the Web that such cross-border links can be made seamlessly.
It is important to lead by example and to ensure that Web pages are as accessible as possible to readers with disabilities, particularly those with visual disabilities. A wealth of guidelines on achieving accessibility exist, but the WAI Reference List on Web Accessibility is a good starting point.
Best use is likely to be made of the home page as a starting point if its URL is short but meaningful (e.g. http://www.poppleton.ac.uk/project). Once the home page exists its existence must be made as widely known as possible. It should be registered with search engines and the owners of related pages are usually willing to insert links if asked.
Setting up a home page is only part of the job; maintenance is also vital. The Data Manager must ensure that the information is kept up to date as the project progresses. New publications must be added to the list as they are completed.
| Top |
11. Resources
The Technical Annex must include an allowance for management time to be spent on the tasks outlined above. Assuming the facilities will be provided by a Computer Centre, then money must be budgeted to pay for them. While it might be reasonable to expect the Computer Centre of one of the partners to provide the facilities as part of its normal load it is better that it be recompensed for its contribution. That way, the project has a right to insist on an appropriate level of service.
| Top |
12. Conclusions
The aim of this short paper is to pass on the benefit of experience on one Tide project to those working on other future projects, to facilitate their smooth running. it is to be hoped that they will learn from our successes and errors.
| Top |
13. References
Rosenoer, J. (1997). CyberLaw. New York: Springer.
Weber, G., Bornschein, J., Mager, R., Engelen, J., Bauwens, B., Evenepoel, F., Victoir, A., Edwards, A. D. N., Stevens, R. D., Malese, B. (1997). Maths Project Final Report, Tide Initiative, Deliverable D10.
| Top |
Appendix: Technical details under Unix
Access structures
It is easiest to set up an account for the Data Manager, which will be the owner of all the files. A group should also be set up so to which all the other consortium members will belong. (For instance, Figure 1 is based on a login name of project for the Data Manager, and a group pgroup to which all consortium members belong). Thus the default protections on files should be read-write for owner, read for group and no access for others. It would be possible to give each member or site of the project their own login, but this is probably unnecessary. Instead one login (and password) should be sufficient - and less unwieldy.
| Top |
Email management
Mail to a user at a Unix site normally gets directed to a directory called /usr/spool/mail. That is to say that the user with login name alistair has a file called /usr/spool/mail/alistair. Mail arriving for that user will normally be appended to the end of that file. However the file can instead contain commands.
For instance, if the file /usr/spool/mail/project at the site poppleton.ac.uk contains the text
Forward to foo@site.domain bar@another.edu archive
Then mail sent to project@poppleton.ac.uk will end up being sent on to foo@site.domain and bar@another.edu. The user 'archive' should be established locally such that all mail sent to it is appended to a file which can be read by all consortium members. By default that file will be /usr/spool/mail/archive, but it might be linked to another file, readable by members of pgroup in an easily accessible directory.
| Top |
Footnotes
UNIX is a trademark of UNIX System Laboratories, Inc.
Microsoft is a trademark of Microsoft Corporation.
PostScript is a trademark of Adobe Systems Inc.
Zip is a trademark of Iomega Corporation.
| Top | |TIDE 98 Papers |