Draft Project Plan

Author: Phil Hobbs
Date: 5th June 1995
Version: 3.1
Document Ref No:
Notes: Subject to revision. Revised to v3.1 as a result of discussion at the Executive Committee meeting 1st December 1995

This document details the ROADS project plan. The current version is for discussion only.

1. Objective of the Project Plan
2. Terminology
3. Description
4. Organisational Structure
5. Stakeholders
6. Roles and Responsibilities
7. Core Documentation
8. Additional Documented Agreements
9. Project Timetable
10. Evaluation
11. Proposal for establishing requirements specification

The Project Plan sets out the key goals of the project and how they are to be achieved. It is the basic document that controls the development of the project. Changes agreed to the project’s strategy or practice will be reflected in revised versions of the Project Plan and any associated documents.

ROADS: System Provider
Service Provider: eLib ANR Service Provider (i.e. ROADS User)
Trusted Provider: Information Provider
End User: ANR Service User

The Project Plan divides-up the project into six phases and four components.

These components are:

• Technical/System Development - the ROADS software
• Evaluation - feedback from information users/end users on the effectiveness of the delivered software versions in meeting the design goal
• Liaison - internal and external liaison between partners/users
• Research - to investigate existing metadata formats and feedback into refinement of template usage in ROADS, to advise and support participants on information retrieval issues and subject based access.

The six phases of the project are:

• Definition
• Design
• Implementation
• Test
• Installation
• Support/Training/Maintenance

Each phase is iterative within itself and that which precedes it. Outside of the six phases there exists a project management/co-ordination service.

For the purpose of this project the Technical component has been identified as the spine. As a result the other components are melded to fit with the schedule and development plan agreed for the spine component.

The organisational structure of the project will be based on the agreement set out in the Consortium Letter of Understanding. This establishes an Executive Committee on which each project member is represented. In addition it has been agreed that Service Providers, through COUSNS, should be involved in the project’s organisational structure. The schematic outline is set out in Annex 1. The wider involvement of End Users and ANR Service Providers will be encouraged through the liaison and evaluation activities of the project.

The following are the identified stakeholders in the ROADS project and are to be involved in decision making and project planning:

• ROADS Partners (Represented by nominated members and project staff)
• JISC/ISSC (represented by Richard Heseltine)
• ANR Service Providers (represented by COUSNS)

During the project named individuals will have responsibility for specific tasks/duties, these are as follows:

For each component documents will be prepared which set out the agreed tasks and processes for that phase. These may be developed independently or jointly, depending upon the degree of inter-relation. The following table indicates the groups involved in developing each set of documentation and the lead group responsible for ensuring discussion/production in line with agreed project standard.

The project has agreed the following additional documentation.

9.1 Task List

End-Users

1. On-line questionnaires will be mounted on ROADS every 3 months (January, April, July, October 1995; January, April, July 1997). Analysis will be ongoing throughout noting changes in patterns of use throughout the project period. The results will be fed back to service providers and trainers.

2. In-depth post-training follow-up of SOSIG users at specified sites and subsequent changes in working patterns. Analysis will be ongoing with results being fed back into training, documentation, publicity materials, and service providers. Reports on End-user evaluation every 6 months (June, December 1996; June 1997).

Service Providers

1. A survey will be carried out at 6 monthly intervals on the perceived success and effectiveness of being associated with ROADS. A particular focus will be on the changes the Service has to make to be involved within ROADS and any changes in use which occur as a result of ROADS use. (February, August 1996; February, August 1997).

2. Follow-up interviews will be carried out with a subset of Service Providers to obtain more in-depth information about working within ROADS. Reports on Service Provider evaluation every 6 months (April, October 1996; April 1997).

Institutions

An annual survey will be conducted to ascertain how use of subject based services effects the delivery and take-up of library and other networked services. A particular focus will be on the technical and support requirements on institutions making use of networked services. (May 1996; May 1997).

Aim
he project plan identifies two 'major' ROADS releases of the ROADS system. These will build on the prototype ROADS v0 already developed by LUT in conjunction with SOSIG and OMNI.

There are now potentially more service providers involved in the development process, and all the service providers will be working to different schedules. In order to ensure the ROADS system develops into an effective product, requirements must be input to the design process in an effective way.

A third release is planned within the project, but as the content and purpose of this release is yet to be agreed , it may be appropriate to input requirements in a different way.

Criteria

1. The need to implement a system (comparatively) quickly
2. The need to involve a lot of people from different institutions; we must ensure they all have a chance to input requirements
3. The need to allow for the fact that the service providers are working to different timescales: everyone is starting at different times, and will have different priorities at different times.

Recommendations
Prototyping will be essential to test the technology, and to enable informed input of requirements. It will speed things up (requirement 1).

In order to ensure all have a chance to consider prototypes and formulate their requirements etc there will need to be a period of time scheduled for requirements input for each version. During this time all ideas/suggestions remain 'on the table'. All prototype 'versions' remain accessible and open for comment. Prototyping will not be seen as a linear process, it will be valid to suggest we combine different aspects of different prototypes. Discussion on the lists (open roads and COUSNS) will be encouraged and regarded as input. There will also be a meeting (or meetings) of interested parties as required. Consensus will be reached by consideration of discussion over the mailing list, in conjunction with meetings and written documents.

There will be a high level document produced to mark the end of the requirement phase, and a design document will also be produced. Both of these will be used to mark approval by the Executive Committee.

As part of the requirements phase we need to consider the implications of a rapid turnover of 'minor releases' or 'versions' (benefits and disadvantages) and consider the number of iterations of requirements/development we can all manage.