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.