Who to and why
Any plan to embed a repository in an institution will have a number of stakeholders, and some of those will be involved in signing off the plan and giving authority to go ahead. However, other stakeholders may be very influential on the decision, especially as getting the full benefit from an embedded repository will need other people (and academics in particular) to give time to carrying out regular tasks. Both groups need to accept the logic of embedding the repository and that the plan represents a good use of resources.
A key part of this logic is to show the link between the need to embed the repository and the institution’s strategies and priorities. The main strategies likely to support embedding are those which imply improved access to the institution’s research outputs and links between research output, overall expertise and personal skills. This may mean (for example) a focus on the REF, increasing research income from outside the UK, or perhaps a strong emphasis on the value of an embedded repository for engagement with businesses and the community in joint research projects. Institutional strategies may also indicate internal priorities (such as efficient use of ICT systems or reducing duplication of processes) that will support embedding.
Care should be taken: the links to strategy should be seen as real, rather than opportunistic or tokenistic. Strategy is rarely interpreted simply: it may be useful to identify a receptive senior manager who is able to give guidance on the way in which articulated strategies are likely to be put into practice.
We felt it [the repository] was a big opportunity for the university to promote its research outputs in many ways it had not done before… we saw the Open Access agenda as a way of supporting that rekindling of promoting the university.” Professor Steve Beaumont
This section of the guide is concerned with working out the costs as much as benefits, but repository managers will need to include benefits when they are building the business case to ask for resources. A good introduction to developing a business case can be found here.
The benefits of an embedded repository will need to be articulated in the business case. The case studies illustrate some of the main benefits, and more details can also be found in the section Drivers, benefits and barriers. The main categories are:
- Improved visibility of the institution’s research outputs by increasing the range of channels that give access and are indexed;
- Increased visibility may increase the institutions research income
- Increased opportunity for collaborative work with other institutions
- Increased opportunity for work with businesses and the community
- More effective organisation for submitting outputs for the REF;
- A comprehensive, bibliographically managed database of research outputs;
- A single managed workflow for making research outputs available in a variety of repositories;
- Linking research projects and their outputs more efficiently.
- Increasing the number of full text items in the repository
Working out what is needed
What needs to be done: gap analysis
The first step to working out what needs to be done to achieve successful embedding is to make an assessment of the gap between the degree of embedding to be aimed for and the position the repository is in at the moment. See the Scenarios to help define the final objective.
The next step is to assess what specific actions are needed and how much they will need in terms of money, people and time.
It is unlikely that the first version of any plan will be perfect. Iterations can be expected because some or all of the following happen:
- Circumstances change (e.g. an overall reduction in funding)
- New information or better data becomes available
- Institutional or other priorities or strategies change
- Management requires changes
- Resources are changed, increased or reduced
- Technical limitations close off all or part of the chosen implementation
The plan will need to be adapted at each iteration. It may need to be resubmitted to stakeholders and/or funders if the changes are substantial.
Specification and requirements
The gap analysis will lead to a specification and a set of requirements. The requirements process is always one of the most complex for any business case. The JISC InfoNet business case guides mentioned earlier give a good overview of what is needed, but there are some special factors for a repository embedding project:
- Existing workflows may be in limited use but problematic if disrupted;
- Existing repository infrastructure may have been selected for core functionality, and may not prioritise interconnectivity with other systems and interfaces for more varied tasks;
- Overlapping functionality with systems such as publication databases;
- Strategic drivers such as the REF and business and community engagement may not always factor in existing repository functions;
- Use of repository to retrieve articles may be low, leading to reduced status in the view of senior managers and academics;
- Existing infrastructure may use different standards from other systems.
In summary, the specification should be driven top-down by the business case, and should include:
- Identification of workflows and business processes that need to be introduced or changed ;
- Identification of the people affected by those changes;
- An overview of the ICT systems that will need to be developed or modified: this should include a review of whether anything from the current repository infrastructure can be retained or whether everything must be replaced;
- Outline definition of the functionality of different interfaces.
The “gold standard” for budgeting is to be able to specify the Total Cost of Ownership (TCO) over the expected lifespan of the initiative. However, this may not be achievable for something like an embedding initiative, where a lot of the cost is going to be the time spent by users.
The main direct cost headings to be considered for achieving an embedded repository are:
- Acquisition of hardware;
- Necessary software licences;
- Fees paid to external personnel, especially development teams;
- Travel and subsistence expenses;
The main indirect costs for an embedding project are peoples’ time and the use of shared resources.
There are two main groups of people needed for a successful embedding project: people whose time will be paid for and costed in (for example, IT development teams) and those whose time is essential but will not will have any costs attributed to them (academics acting as guinea pigs, for example).
The costs of external development teams should be included in direct costs.
The key people whose time may be costed into a project are:
- The repository manager
- IT manager
- IT design and development staff
- Research office management and staff
The TRAC methodology is the best place to start as it is used across the entire higher education sector. There may occasionally be some strong local reasons for using another approach, but the standardisation TRAC brings has great value.
There may be some need to cost in time for people less directly involved:
- Senior managers
This can be very hard to estimate. However, it should be done if possible (at least at the individual level) because stakeholders are likely to ask about the impact on themselves or their colleagues, and because if it is underestimated implementation may go slowly or come to a halt because those affected are not behaving as predicted.
The estimate is probably best worked out through a quick reality check on the effort an individual may have to make (e.g. an academic may take 15 minutes to enter details of an article; the average publication rate is four per year; and there are 1,500 relevant academics.) This can then be aggregated as appropriate and TRAC methods applied to calculating a cost if required. However, it is worth noting that the most problems are likely to arise from limitations on the time people have available, and resistance to taking on additional tasks, rather than the absolute cost of that time.
Estimating the costs of shared infrastructure such as servers and networking may be required by some institutions. Even an embedded repository is unlikely to place heavy additional demand on resources, so care should be taken not to overestimate the value of shared resources. The institution may have a formula for calculating use of shared resources. There may be a transfer of responsibilities for hosting and technical support for the repository when it becomes part of an embedded system, perhaps with budgetary implications.
It is important to develop a realistic timescale as well as calculate the person-days. The timescale depends partly on the person-days, but also on a range of other factors, including:
- Co-ordination with other projects that you may not have control over
- The pace at which the institution can change
- The availability of funding, which may come in tranches spaced over months (or even years) rather than allocated as a lump sum
- Dependencies within the plan
- Dependencies on internal resources
- Dependencies on external processes
- Dependencies on external resources such as developers
In the light of our definition of embedding as having as much to do with culture as with the technology, the timescale should not end when the last technical piece of the project is working; rather, the plan will be completed when the resulting processes and systems are widely adopted by the target user groups. It is very important to specify this realistically when making the business case; embedding projects, especially ones which require a lot of co-operation from individual academics, will be hard to justify if the follow-through to actual adoption is not planned for.
Communicate the benefit to the institution, that’s absolutely crucial. So you need to explain to me why the University of X should, how it would benefit from something like this.” Steve Beaumont’s advice to repository managers
Those signing off on the initiative will need a clear and realistic appraisal of the risks entailed. Institutions may already have a standard form for risk assessment. These include technical risks, financial risk and organisational or cultural risk. In the case of embedding a repository, because the implementation is likely to involve users from across the institution, the risks are less likely to be simply technical, and more likely to be financial (system integration projects are prone to time and budget over-runs) and organisational (resistance from stakeholders may render the project hard to implement or lead to low use when implemented.)
Project managers should also seek to enlist the senior management in managing those risks which they themselves cannot overcome; one of the main things that they can ask for at this stage is that senior managers support them both proactively (endorsing the development publicly) and reactively (backing it against discontent expressed by their colleagues.)
It is here that some of the main technical issues become important. Stakeholders and senior management signing off on the initiative will want a clear overview of the functional requirements (but not exhaustive detail) and an understanding of how these will fit together with things that are already in place or have already been commissioned.