Recommendations

The development of the IR proved yet again that nothing proceeds according to plan and that the project team had to be ready, willing and able to adapt to changing circumstances. The value of networking and sharing of knowledge proved to be invaluable in ensuring that the project was completed within the allotted time span.

The team’s flexibility, with the required level of quality and expertise being retained, proved to be one of its most valuable features. The project was completed according to specifications, within budget and on time and the results were more positive than originally anticipated.

However, mistakes were made. It is necessary to acknowledge these and to list the actions taken to address and resolve the resulting problems.

The first problem occurred during the trial phase and resulted from the decisions taken at the time. It is not feasible to use a temporary structure with the aim of

fine-tuning it later. DSpace is not flexible enough to accommodate fine-turning at a later stage, as all existing records have to be changed manually. This will result in a lot of repeat work and will prove to be costly unless an alternative solution is found.

The project team resolved this issue by changing its approach – a decision which, although proving to be beneficial, could easily have resulted in abandonment of the project.

The second problem occurred during the planning of the structure. The original decision was to keep it simple and to move away from the structure of the organization. This decision proved to be unacceptable to the stakeholders and had to be adapted during the development phase. A lack of consultation between the team leader with all the stakeholders to identify their needs was the direct cause.

Adaptability again enabled the project team to resolve the matter quickly and easily.

The lack of standards and quality control systems within DSpace proved to be a bigger problem than anticipated. However, implementation of the workflow system will address this problem and it will also be of value should DSpace in future be replaced by another system. Also, as the repository is a subset of another quality- controlled system, this shortcoming can be accommodated. It is not clear what will happen when the ‘mother-system’ changes or how this will affect the repository. Any changes to either system will have to consider the impact on the other.

Compression of video files and long-term preservation of all formats are still challenges that must be resolved. Although plans for these have been tabled, they have not yet been tested and this is still a major concern in terms of sustainability.

The whole issue regarding obsolete or outdated software and hardware must be investigated properly. Risk assessments must be done and projects launched to formalize the migration of data to current products. This is an ongoing process and to date there has been a lack of sufficient or ongoing planning.

The following recommendations should be of value to anybody planning an IR.

•

Verify the accuracy of statements and avoid ‘technical’ assumptions. For example, the IR team assumed that the export of data from UPSpace could easily be manipulated and moved to other communities and collections. This proved not to be the case and an alternative had to be implemented. In general, this can be attributed to assuming that shared understanding existed. This not only caused delays at the beginning of the project that could have been very

costly at the end, but also necessitated changes to the original project plan.

Especially when people from different backgrounds are involved, it is essential to ensure that there are no misconceptions and to communicate any changes as soon as possible. Prior experience with similar products created a false sense of security that might have proved to be costly.

•

Communication proved to be a challenge. When a dedicated team is not available, communication increases in importance and it is essential that the team leader be kept aware of what is happening in the other areas, as well as where there were necessary changes in priorities as a result of unforeseen circumstances. As the project team consisted of members from other units, it was often difficult to get the entire team together on short notice. This resulted in having to rely on email communications for decision-making, leading to miscommunication and delays. The result was conflict and stress that could have been avoided.

•

All issues regarding branding should be resolved prior to the implementation of the system. Because of communication breakdowns, the branding of the repository was delayed. Although this did not influence the developmental work, it could have delayed the launch of the official product.

•

The structure of the repository should be finalised prior to implementation of a trial project. Working as close to reality as possible is the only reliable way of testing the product. It might not be easy or even possible to ‘fix things’ with the final product.

•

Proper planning should resolve many issues and would make the process easier.

However, time should still be allocated to resolve issues such as staff turnover, essential expansion of the original scope of the project and delays caused resulting from the unavailability of critical personnel. It is therefore essential to plan for backups and to be open to alternative solutions.

•

As the work was done by a virtual team, typical problems, e.g. breakdown in communication and delays due to external influences had an effect on the smooth running of the project. However, as the virtual team was geographically situated on the CSIR campus, it was able to solve problems quickly and effectively. However, should the members of the virtual team be geographically separated, care should be taken to arrange video conferencing for effective resolution of problems.