I-WIRE Requirements: Part 3 - User Needs and Design Phase Scope

This is the final in a series of blog entries that has summarised the findings of the I-WIRE project's User Needs Analysis phase, ending with this summary of the requirements captured during the Future State modelling group session, and during interviews with Research Administrators.

1 Guiding Principles

3 User Stories 

I-WIRE Requirements: Part 2 - Current State Process and Issues

This is the second in a series of three blog entries that will summarise the findings of the I-WIRE project's User Needs Analysis phase, continuing with this summary of the Current State process that was captured during the group session with academic authors, and the issues associated with it.

1 Lean Group Session

During the Lean group session with academic authors, the management of research publications was examined end-to-end, from the initial research opportunity through to the various reports that are produced by the Schools.  While the scope of the I-WIRE project is only one part of the end-to-end process - specifically around the deposit of items into the Repository - the end-to-end process was examined in order to identify any opportunities for improvement or automation of the deposit workflow by potentially integrating with other processes, and also to identify opportunities for re-use of the publication data and elimination of wasted effort.

The following two diagrams illustrate the main steps in the end-to-end process.

2 Summary of Issues with Current State Process

2.1 Open Access

The following issues were raised during the group session and continually throughout the interviews, and are perceived as blockers to Open Access depositing:

• Complexity and uncertainty around the whole area of copyright policies and which version of articles can be deposited where.  Some authors admit to often signing away copyright with little attention to it, and would like the School or University to manage copyright negotiations on their behalf, freeing them up to get on with the next piece of research.  This could include retention of copyright (particularly for conference papers) or permission for deposit in Institutional Repositories.
• The final version of an article is 'king', and generally cannot be deposited anywhere other than with the publisher.  And it's important to be published in the right journal that has a good impact and the right audience.  However, there can be up to a year between submission and publication, and differences between on-line and paper versions.
• The perception that target audiences will have access to articles through journal subscriptions anyway, so depositing to an Institutional Repository is an unnecessary step.
• Academics don't have the time to deposit so anything beyond a single click is too time consuming, and there are databases that already collect this data (Web of Science, etc.) on behalf of the author.

2.2 Improving the Deposit Process

The current process is seen as taking too long and requiring too much data to be keyed by the depositor.  Academics want 'maximum output with minimum effort'.

Any new process needs to be flexible enough to cater for different approaches and requirements across the different schools.  For example, the School of Medicine are running Symplectic which gathers their publication data for them, and are happy that final versions are available from the publishers through existing subscriptions.  In contrast, outputs from the School of Journalism, Media & Cultural Studies won't neccessarily be covered by a single database, and therefore have to be deposited manually.  Plus they have a lot of conference papers that could be included in the repository if an expert could help with the less-than straightforward copyright policies.

2.3 Re-Use of Publication Data

It's not feasible for the repository to serve the needs of every School in terms of the reports that they have to produce.  This is due to local organisational hierarchies and the application of local data and rules to enhance the publication data, and therefore there will be a need for ORCA to provide raw publication data for the Schools to enhance and manipulate themselves.  However, the many different outputs proposed, and access to metrics, may not be as valuable for the humanities based Schools as the sciences.

Research Administrators often have to chase academics for up to date publication lists to be used in a variety of processes such as reports to School Boards, web site updates and appraisals.  Academics get annoyed if they feel they are giving the same information to a variety of places.

2.4 Balancing the Needs of Different Schools

Balancing the needs of:

The science based Schools, focussed almost exclusively on final versions in journals made available through subscriptions; with little concern for copyright and wanting to have very little manual input (if any at all).

The social science and humanities Schools, with a variety of output types and destinations and no single database giving them complete coverage, so more open to having to capture their publication data themselves, and therefore with more concern for copyright.

The next and final blog entry in this series will summarise the requirements captured during the Future State modelling group session, and during interviews with Research Administrators.

I-WIRE Requirements: Part 1 - Approach to User Needs Analysis

This is the first in a series of three blog entries that will summarise the findings of the I-WIRE project's User Needs Analysis phase, starting with this entry on the approach taken by the project team.

1 Project Overview

The I-WIRE project aims to develop a workflow and toolset, integrated into a Portal environment, for the submission, indexing, and re-purposing of research outputs in ORCA (Online Research @ Cardiff) - Cardiff University’s Institutional Repository. This will be based on requirements gathered from academic Schools and administrative Directorates in the University during a User Needs Analysis phase - the subject of this Requirements Report.

The impetus for the project comes from a decision by the University Research Committee to approve the mandatory deposit of new publications in ORCA, subject to detailed consideration as to the means by which staff up-load data to the repository.

The I-WIRE project’s primary aim is to develop a submissions and metadata workflow that minimises staff effort and offers other value added services that will encourage use and in particular author self deposit of new publication data. There is also an increasing need for the University to create and maintain an up to date, central publications database in preparation for the REF

2 Stakeholder Identification

The following communities were identified by the project team as current or potential users of ORCA, and therefore key Stakeholders in the I-WIRE project:

• Researchers and academic authors in all Schools through their need to make their research outputs available on an Open Access basis. 
• Research Administrators in all Schools through their need to provide reports on the School's research outputs.
• The Repository Manager and Subject Librarians through their responsibility to ensure the quality of metadata in ORCA. 

Other Cardiff University staff in the Schools and Directorates who expressed an interest in either ORCA or the project itself during project initiation - but fell outside the above communities - were also included as Stakeholders.  For example, interest in the project was expressed by Web Managers looking for ways to automate the population of publication lists on web pages.

3 User Needs Analysis Approach

By the time the I-WIRE project team was in place and the User Needs Analysis work package was able to start in October 2009, the project was six months into its two year fixed life cycle and was at risk of missing the scheduled delivery of the Requirements Report at the end of December 2009

The project team gave full attention to the User Needs Analysis work package and agreed the methods that would be used to provide as much coverage of the stakeholders as possible in as short a time as possible.  A schedule was drawn up that would see the majority of stakeholder interviews completed by the end of December 2009 and the analysis take place during January.

Giving consideration to the key stakeholders being spread across 29 Schools - of which each School has its own systems and processes - and numerous supporting Directorates, and the short window of opportunity, the project team agreed to carry out the following key activities in parallel through October to December 2009:

3.1 Communications

The project team arranged for a series of communications and agenda items at related meetings and committees to ensure awareness of the project and its objectives, and to seek support from key stakeholders where required. 

3.2 Interview Research Administrators

A structured questionnaire was developed and piloted with the partner Schools in order to consistently capture requirements during each interview, and to steer the conversation to provide maximum coverage of all topics.

With the assistance of Subject Librarians, the project team arranged to interview the Research Administrator in each School.  Some of these interviews also captured the requirements of authors through the attendance of Research Directors or Heads of Schools.

Due to the short window of opportunity, the Schools were scheduled in order to give a good cross-section of science based and social-science / humanities based Schools, with the intention of covering a minimum of one third of the Schools by the end of the work package, and more if feasible.

The project team agreed to capture all requirements raised during the interviews, regardless of whether the requirement was within the scope of the project or not, with the intention of passing out-of-scope requirements to the Repository Manager during the analysis phase to inform the longer term repository roadmap and other projects.

3.3 Group Sessions with Academic Authors

The project team brought together a group of authors from the partner Schools - identified by the Research Administrators - in two workshops facilitated by the Cardiff University Lean team, to:

capture and document the Current State process that authors follow for the management of their publications, along with associated issues.  The process was looked at end-to-end from identification of research opportunities to production of reports for Schools management, in order to identify any opportunities for linking the deposit process with other processes such as Performance Management.  The Current State process has been documented as the project baseline in order to assist with evaluation of the project’s outcomes; and

agree and document an enhanced and simplified Future State process that the same set of authors agreed would encourage them to self-deposit in the repository, along with other requirements that they may have.

3.4 Interview Other Interested Stakeholders

The project team also arranged to interview staff in the Schools or Directorates that expressed an interest in the project or ORCA through the communications sessions or other groups and committees.

The following diagram illustrates the stakeholders interviewed and the interview schedule.

 
4 User Needs Analysis

Analysis of the captured User Needs - as expressed during the interviews and group sessions - is critical to ensure the scope of the project is sized appropriately and to give the project the best chance of a successful outcome.

The project would be at risk of delivering a disjoint and overly complex solution if requirements were taken at face value without analysis.  The analysis took place in the form of a series of group sessions during January 2010 made up of the project team and the technical development team, and focussed on:

the most frequently occurring requirements expressed during the interviews;

implementing the requirements in as neutral a manner as possible to ensure the most value can be obtained by multiple Schools being able to use the solution, and not delivering bespoke solutions that cater to the needs of just one School or stakeholders;

what can feasibly be delivered in the project's timescales, bearing in mind available budget and resource; and

solutions that utilise EPrints functionality and features as it is delivered ‘out-of-the-box’, and remain aligned with the EPrints software roadmap and do not deviate from that to such an extent that the EPrints upgrades become difficult and costly in the future.

With these points in mind, the project team worked through each requirement (grouped into themes), and produced User Stories for the requirements that can be delivered in the project's timescales.  The User Stories express the requirements in a neutral manner, written from the end users point of view to ensure the requirements provide value to the end user, and written with Acceptance Criteria that can be used when it comes to testing the solution.

Requirements that the team agreed are not in scope of the project have been notified to the Repository Manager for consideration in the longer term repository roadmap and other projects.

The next blog entry in this series will explain the Current State process that was captured during the group session with the academic authors, and the issues associated with it.