I2: Product quote guidance

1. Purpose of the Product Quote document

The Product quote is the first document in a standard project lifecycle that is intended for an external audience (i.e. beyond the RSE team).

The Product Quote will form the basis of the contract under which development work will be undertaken by the RSE Team. As such, the suggested language is necessarily legalistic and as comprehensive as possible. Typically the Product Quote will be authored by the same team member (typically an Analyst) who authored the Feasibility study. This document makes extensive use of boilerplate text segments as many of the obligations and protocols governing one project will be similar for others.

The text should be composed in such a way that, wherever possible, a project PI preparing a funding application can make direct use of the prose in the appropriate sections fo their funding application, albeit with some guidance from the RSE team.

From a workload perspective, much of what was prepared for the Feasibility report can be reused in the Product Quote. It will be appropriate to edit out some of the more discursive elements and ensure a professional tone.

2. Completing the Product Quote

2.1 OVERVIEW section

This section is intended to provide a summary of the research project's goals and methodologies and may also include some relevant formative information about the origin of the project. Most importantly it gives the commissioning Research team another opportunity to ensure that their needs have been understood and correct any omissions or errors. Typically this content can be mostly reused from the ToR and the Feasibility report.

2.2. REQUIREMENTS section

In practice this section _should _ be directly transferable from the Feasibility document, having been reviewed by the appropriate members of the RSE team.

2.3. SOLUTION ARCHITECTURE section

Again the majority of this section could be resused from the Feasibility document. It is important, as far as possible, to ensure that the language used here is not overly technical so that the research team are able to understand clearly what is being proposed as a technical solution.

It is intended also that this text can be reused in the main funding application and it should be considered that it will form the basis of a technical review of the application. Rationale for using a particular technical strategy should be clearly stated.

To assist with creating a Justification of Resources statement it is helpful to describe at a high level the involvement of the SDLC roles in the development.

Example Questions and prompts	Check
Does the proposed technical solution take into account data standards?
Does it, or will it ultimately, adhere to FAIR principles?
Is it clear that the RSE team has sufficient expertise to implement the solution?
Is the solution scaleable? Does it need to be?
Which RSE roles will be performing which tasks?

2.4. ALTERNATIVE SOLUTIONS section

For the technical review it is important to demonstrate that alternative technical solutions have been considered and to justify their dismissal as viable options. The reasons for dismissing these options might be technical, time or cost related, skills related, sustainability related.

2.5. DEVELOPMENT APPROACH section

The research team are signing an agreement when accepting the Product Quote. It is important that expectations about development practices are clearly communicated and can be referred to during the project lifespan.

Example Questions and prompts	Check
Where will the evolving solution be hosted?
What backup strategies are in place?
Which channels should the research team use to seek or provide feedback?
How often will review meetings take place?
When will change freeze be implemented?

2.6. DELIVERY PLAN section

The nature of Agile RSE means that the priority of the requirements can change from one development increment to another. The software is being developed in parallel with the research and it should reflect progress being made. For this section the development targets of the first increment should be clearly stated. Depending on the size of the project, a common sense approach is needed as to what level of detail should be specified for the second and subsequent increments.

2.7. MANAGEMENT APPROACH section

How will the project be managed? This documentation tends to assume that a variation of Agile is being implemented, but your institution may manage things differently or even change strategies on a case by case basis. Who will be the main point of contact for the research team, and how will progress be acheived and recorded? Which other SDLC roles will be assigned to this project?

2.8. OBLIGATIONS section

It should be made clear that as well as the RSE team committing to producing a Minimum Viable Product (MVP), the research team are accepting the processes and procedures that are necessary to complete the work. The RSE team should reasonably expect that their requests for feedback and testing are responded to in a timely fashion. For the avoidance of doubt, it may be helpful to specify fixed timeframes for reponses.

2.9. LICENSING APPROACH section

Make it clear who will own the intellectual property of the digital research and if it is jointly owned or if one or other party has particular rights over a certain aspect of the digital outputs.

2.9.1. Software

See the Product Quote template for sample boilerplate.

2.9.2. Research data and content

See the Product Quote template for sample boilerplate.

2.10. CREDITS, CITATION AND IDENTIFIERS section

Within the RSE community there is a perception that traditionally, the RSE team's input to the project has not been sufficiently stated.

This section gives an opportunity to specify when and where the team should be acknowledged and should be referred to throughout the project. See the Product Quote template for sample boilerplate.

2.11. FORWARD PLANNING

The content of the Forward Planning section may vary considerably between institutions (depending on their policy) and between funders (depending on their requirements). See the Product Quote template for sample boilerplate.

Typically, this section should aim to cover the following headings:

2.11.1. Web Hosting and Infrastructure Service Level Agreement (SLA)

2.11.2. Archiving and Sustainability

2.11.3. Research Data Management

2.12. COSTINGS

The costings table provided in this section can be concise and should summarize the cost of development, administration and infrastructure for the period of the project's activity.

2.13. APPROVAL

If any part of the Product Quote needs to be amended or reviewed this should be done prior to the delegated Research Team member signing the document.

NB. The Product Quote should be signed by the PI prior to any application being submitted, and then countersigned by the designated RSE team member

	[RSE Representative]	[Project Representative A]	[Project Representative B]
Name
Role
Signature
Date