F2: Feasibility guidance

1. Purpose of the Feasibility document

The Feasibility document is the product of a scoping and investigation stage, which aims to:

• Evaluate technical and methodological approaches for the RSE team to address project requirements
• Formalise the prioritisation of the project requirements
• Make accurate projections for the time needed to address the project requirements
• Make accurate projections for the specifications of the infrastructure that will be needed to address the project requirements
• Use these time and resource calculations to determine development and maintenance costs
• Identify a suitable forward planning strategy
• Ensure that all appropriate RSE team members peer review these recommendations and suggest amendments prior to proceeding to the Product Quote document.

The Feasibility document will be the product of collaborative efforts from within the RSE team to assess how practical the proposed project is and to ensure that proper consideration is given to the likelihood of a successful outcome. At a minimum, a successful outcome would be considered achieved if all Must Have requirements are completed at the end of the project. The most effective assessment will be ensured if opinions are sought from all RSE team members who will be involved in producing the requirements and from those with specialist experience.

At this point, a collective decision by the RSE team has been made to investigate the Feasibility but this does not preclude a subsequent decision that the project in its current form is not feasible. An evolving understanding of the research goals and the context of the project may feed into this decision.

In discussing the Feasibility as a team it is necessary to suggest suitable time allocations for the various tasks that can be agreed upon. A High Level Cost calculation spreadsheet can be used to model time allocations.

It is intended as an internal facing document, though considerable portions of this document may be reused in the creation of a Product Quote and may be used in technical appendices to a funding application.

Unlike the Terms of Reference document, the Feasibility must be peer reviewed internally and approved before progressing to the Product Quote stage.

2. Completing the Feasibility

2.1 RESEARCH CASE section

This section requires a considered justification for the project from strategic perspective. This section must demonstrate that the project has research value and is in alignment with the strategic goals of the RSE team and the wider institutions involved. The content of this section might borrow considerably from the completed Terms of Reference document, in particular the Background Context section.

Example Questions and prompts	Check
What distinguishes this research as particularly ambitious or innovative?
Does the project align with current internal goals and strategies?
Does the project align with internal research interests?
Does the project offer an opportunity to engage with new technology and approaches?
Does the project offer an opportunity to develop a mutually beneficial strategic relationship with an interesting partner?
Does the project align with your institutional values and ethical considerations?

2.2 REQUIREMENTS section

This section builds upon and refines the project requirements identified in the Terms of Reference. High level requirements might be broken down into more specific tasks and new requirements may emerge after consultation with Developers and UI/UX Developers that are pre-requisites for other requirements. As before, all requirements should be considered from infrastructure upwards, and it may be helpful to apply the same tests as before:

• Must Have requirements (M) are those that would compromise the rationale of the project if not delivered. Test whether the core goals of the research can still be met, even at considerable inconvenience, if this requirement were not fulfilled.
• Should Have requirements (S) are those that would significantly improve workflow and reduce inconvenience for users attempting to achieve a core goal of the research. Additionally, these requirements, if not directly applicable to a particular M requirement, may be of secondary importance to the core research goals.
• Could Have requirements (C) are those that provide marginal improvements in workflow and may be aesthetic or of tertiary importance to the core research goals.
• Would Have requirements (W) are those that are likely to be aspirational in nature but present significant technical and practical obstacles given the timeframe and funding proposed. They may present very marginal benefits to the overall project goal, or may be more suited to follow on research pending the successful completion of the initial project.

For the purposes of review and planning it can be very helpful to give an indication of the RSE Roles time allocation in each requirement identified. Typically, the notation A = Analyst, D = Developer, U = UI/UX, S = Systems, P = Project Manager can be very useful for a reviewer to judge whether or not sufficient time is allocated for the tasks planned. Additionally, beyond describing the high level requirements it may be necessary to provide some practical examples of how certain functional requirements might work.

It may be useful to pre-fill default items in the requirements list. Some default tasks are suggested in the template document that cover what should be considered essential work such as user testing, accessibility testing, and deployment. Note that in the template the 'Priority' column may show several alternatives in brackets, eg. [M, S, or W]. For these items the priority is given as as options because the actual priority will depend on the nature of the resource covered by the Feasibility. For certain types of digital output some of these defaults either may not be applicable or will not need to be mandatory. However, for the majority of KDL projects all these defaults will be MUST HAVE. The following table lists the default requirements that have alternate requirements and explains when specific priorities apply.

ID	Requirement	Priority
KDL02	Web accessibility testing	MUST HAVE for any project in which KDL builds a public-facing resource. SHOULD HAVE for any project in which KDL build a non-public resource. Here it is optional because the resource will be non-public, but as a matter of best practice for all users, including private ones, it is still strongly recommended. WON'T HAVE for any project in which KDL is not building a digital resource. Also do not allocate any days in this case.
KDL03	Usability testing	MUST HAVE for any project in which KDL builds a public-facing resource. This testing must happen at least once, but obviously could happen more than once - especially on a multi-year large-budget project. SHOULD HAVE for any project in which KDL build a non-public resource. This assumes testing by project partners will occur throughout evolutionary development. Optionally MUST HAVE if project involves a group of potential private users who are not able to test during evolutionary development. WON'T HAVE for any project in which KDL is not building a digital resource. Also do not allocate any days in this case
KDL04-09	Acceptance testing Change freeze Web accessibility final test & statement Security test Deployment Sign-off of SLA or handover agreement	MUST HAVE for any project in which KDL builds a digital resource, whether public facing or private WON'T HAVE for any project in which KDL is not building a digital resource. Also do not allocate any days in this case

The following are additional guidance notes about several of the default KDL requirements:

ID	Requirement	Notes
KDL03	Usability testing	- should involve members of target audience who are unfamiliar with the application - but also note that if the test object is a redesign of an earlier site, the testers should include users of the earlier version - the requirement description and/or technical solution must state clearly that partners are responsible for supplying & organizing the group of test users - the timing of this requirement within funded period can be variable and should be decided jointly by partners & UI/UX team - the recommended minimum time allocations for this requirement are: A 3 D 5 U 5
KDL04	Acceptance testing	- the purpose is to see if partners agree that resource meets at least all the MUST HAVE requirements - the testing should involve project partners - the timing should be late in development but prior to change freeze
KDL05	Change freeze	- should come after Acceptance testing to allow for possibility that Acceptance testing exposes need for a feature change (obviously this ought not to happen if we do increments & partner review scrupulously, but ...) - time allotment for change freeze should be decided based on the size of the project and the complexity of the application. As a rough guide, reasonable amounts for projects that are Medium sized would be: A 3 D 5 U 5

The matrix below offers some prompts and key questions for effectively completing this section. It is not exhaustive but aims to stimulate internal conversation in a productive way.

Example Questions and prompts	Check
Will the project require dedicated infrastructure? If so, where will it be hosted?
What key services will any dedicated infrastructure need to provide? e.g. Image server, Web server, High Powered Computing etc.
How much disk storage is likely to be required?
Is there a minimum appropriate technical specification for the infrastructure?
Does the project require a website? If so, list the essential user actions that must be accomplished.
What are the key user interactions that should be possible? e.g. textual search, faceted search, free browsing, data entry, moderated contributions, forums, map visualisations, data visualisations, API etc?
Does the project require bespoke data structure? If so, which forms are most suitable? e.g relational database, graph database, XML etc.
Are there domain specific conventions and standards that must be observed, such as data formats, ontologies etc?
What are the design requirements of the website? e.g. a landmark resource with a strong brand identity, limited brand identity with a focus on specialist functionality, or a completely standard backend interface which will only be used by the project team etc.
Will the resource draw upon third-party data or resources?
Will there be consultancy products? e.g. reports, scoping documents, design guidelines, etc.

Categorise these requirements into the MoSCoW classification

TIP: in the Project-specific requirements table don't finalize the requirement ID values until Feasibility is signed off by KDL reviewers; it's a great nuisance to have to change them as requirements are added during review.

2.3 SOLUTION ARCHITECTURE DEFINITION section

This section should provide an overview of the stack of technologies to employed and justification for their applicability.

2.3a ALTERNATIVE SOLUTIONS section

This subsection should cover in brief the range of technical solutions considered and a rationale for rejecting them in favour of the solution outlined in the section above should be given.

Actions	Check
For each requirement, specify the technological solution suggested.
If possible, suggest a fallback solution for each requirement.
Make clear the level of RSE team experience in building solutions from the suggested software stack.

2.4 DEVELOPMENT APPROACH DEFINITION section

This section may be largely boilerplate text and should be specific to the RSE team's implementation of whichever project management model is being followed. This documentation assumes by default that RSEs are using a variant of an Agile workflow.

Example text: [RSE Team's] Software Development Life Cycle (SDLC) uses an Agile methodology whereby work proceeds in increments and the product is iteratively developed. Wherever possible and applicable, unit tests will be created to guarantee the quality and sustainability of the code. All the source code will be hosted in an open source repository on [versioning solution]. Work increments will address prioritised requirements (as detailed above). Each increment of work will followed by an internal review and partner to inform the focus of the next work increment and to re-prioritise the requirements according to circumstances. Work on subsequent increments will not progress until appropriate user tests have been documented by the project team and necessary feedback has been received. Technical documentation will be maintained throughout the project for each of the components developed and for the processes used. The project will employ existing [RSE Team] project management tools for issue tracking and documentation. Project tasks will be logged, assigned and progressed through these tools. A development change freeze will be in effect at XX weeks prior to the end of the project, after which no substantial changes to agreed functionality or design will be undertaken. The project output will not reside on the [RSE Team's] infrastructure beyond the duration of the project without a signed Service Level Agreement with the commissioning project team.

This text should make clear the commitments and responsibilities of the RSE Team and the Project Team in moving development forward effectively, by outlining the key stages of the development and establishing buy-in to the process.

2.5 DELIVERY PLAN section

This section is used to outline the first phases of development and will specify the deliverables to be expected in the first increment. Since this SDLC assumes an Agile methodology, all subsequent increments are informed by the outcomes of the previous increments. It is appropriate therefore that detailed increment plans are reserved for the intervals between increments following a review. Consider what essential underpinning is needed for the development to proceed; infrastructure, software configuration, data modelling, stakeholder workshops, solution scoping etc.

2.6 MANAGEMENT APPROACH DEFINITION section

Building on the Development Approach Definition, this section should make clear the delegation of institutional and individual responsibilities. The Roles needed in the project should be clearly identified, though it is not necessary to specify individuals at this stage.

2.7 FORWARD PLANNING DEFINITION section

It is becoming increasingly understood how important it is to have a long-term strategy for the maintenance of digital research outputs. This section should address the question of archiving and assess the amenability of the digital product to archiving. Useful guidelines for this assessment are provided by Stanford University Press and have been deposited in this toolset as Amenability_to_Archiving_SUP in the Other Useful Guidance folder. This section should additionally consider any requirements the funder might specify about archiving and sustainability and may contain some boilerplate text.

Example boilerplate text: Where funders require, [RSE Team] makes full provision for hosting and maintaining the project’s online resource for a period of XX years beyond the funded period. This provision is included in the costings, and will be formalised in a Service Level Agreement (‘SLA’) that will be signed by [RSE Team] and the project partners prior to the end of the funded period. Six months before the end of the initial SLA [RSE Team] will contact the partners to discuss available options, including ongoing maintenance under a new SLA, archiving and/or preservation to ensure the project is properly managed even in the event ongoing funding is unavailable.

2.8 COSTINGS section

For the purposes of peer review it is recommended that the estimated costs should be itemised as clearly as possible. There is generally no need for this fine level of detail in the final Product Quote but it is essential to keep a clear record of cost calculations, for reasons of transparency, audit, and future planning.

2.9 FEASIBILITY ASSESSMENT

In practice this section should be completed after stage 3.1 detailed below. It indicates that all relevant information and all relevant expertise has been considered. At this point the RSE team will still have the option of rejecting the project as not feasible.

In the event that the project is technically feasible and strategically desirable, other justifications for proceeding might include significant research impact and the nurturing of institutional relationships.

3. APPROVAL section

3.1. Iterative review

Initially the completed Feasibility report should be circulated to:

• Another RSE Analyst (not the document author)
• RSE Developer/Engineer
• RSE UI/UX Designer
• RSE Project Manager

It will be rare that a Feasibility is acceptable in its first iteration and there will almost inevitably be recommendations to change time allocations for particular roles, to promote or demote the priority of certain requirements.

3.2. Sign off

In its final iteration the Feasibility should be approved by the RSE team members who helped to refine its content and additionally the RSE team Director

4. NEXT STEPS

Typically the next stage of the SDLC would be move on to preparing the Product Quote.