Naming convention: [PI Surname] TechP
Before reading this section, please see the Case for Support Guidance regarding a Technical Summary.
A Technical Plan should be no more than four pages long and provided for all applications where digital outputs or digital technologies are an essential part to the planned research outcomes. A digital output or digital technology is defined as an activity which involves the creation, gathering, collecting and/or processing of digital information. For present purposes digital technologies do not include conventional software such as word processing packages and ICT activities such as email.
Please read this guidance carefully and consider its definitions within the context of your own research proposal.
The purpose of the Technical Plan is to demonstrate to the AHRC that technical provisions within a research proposal have been adequately addressed in terms of:
(a) Delivering the planned digital output or the digital technology from a practical and methodological perspective;
(b) Doing so in a way which satisfies the AHRC's requirements for preservation and sustainability. The AHRC has a responsibility to ensure that the research which it funds is achievable and high-quality, and that the outputs of the research will wherever appropriate be accessible to the community over the longer term.
If your project involves the development of a digital output or digital technology as an essential part of the planned research outcomes, but which cannot or need not be preserved beyond the period of funding, you must still complete a Technical Plan, explaining the reasons for not preserving the object(s) in question. In general, as a matter of good practice, the AHRC expects the digital outputs or technologies produced by projects to be preserved for an appropriate period after the end of project funding (see Section 4 below noting the different definitions of preservation and sustainability in this context).
You do not need to complete a Technical Plan if your only proposed digital output or technology consists of web-pages containing information about the project (as opposed to data produced by the project).
Writing the Technical Plan
The Technical Plan must be written as a single document and has a limit of four pages. The level of detail provided should be proportionate to the envisaged value and importance of the proposed digital output or technology and to the cost of developing it.
The Technical Plan must use the following headings:
- Section 1: Summary of Digital Outputs and Digital Technologies
- Section 2: Technical Methodology
- 2a: Standards and Formats
- 2b: Hardware and Software
- 2c: Data Acquisition, Processing, Analysis and Use
- Section 3: Technical Support and Relevant Experience
- Section 4: Preservation, Sustainability and Use
- 4a: Preserving Your Data
- 4b: Ensuring Continued Access and Use of Your Digital Outputs
Each of these headings is described below.
The Technical Plan must be closely integrated with the rest of the proposal, especially with the Case for Support and the Impact Plan. The section on project management in the Case for Support must take into consideration the technical aspects of the project if a Technical Plan is required, and should provide an assessment of risk. Copyright, intellectual property and ethical issues relating to digital outputs and technologies should also be dealt with in the Case for Support. Note that details of the process and timetabling of technical development should be provided under Section 2.c of the Technical Plan.
The Technical Plan will be reviewed in the context of the proposal as a whole.
A. Technical Plan, Section 1. Summary of Digital Outputs and Digital Technologies
You should provide a brief and clear description of the digital output or digital technology being proposed, considering the following aspects: purpose, source data, content, functionality, use and its relationship to the research questions. You should identify the type of access envisaged, if applicable, such as 'freely available online'.
The summary should provide clear overview of what you intend to achieve technically, to enable reviewers to assess whether the plans for achieving this are appropriate. You should provide a level of detail which is appropriate to the digital output or digital technology being proposed and its cost and status within the project.
B. Technical Plan, Section 2.a. Technical Methodology: Standards and Formats
You should provide information about your choice of data and file formats. You must provide any relevant vital statistics relating to the data, such as size, quantity and duration. Although such statistics might need to rely on estimation, you should provide the reasoning behind your calculations. You should give your reasons for using the standards or formats chosen.
C. Technical Plan, Section 2.b. Technical Methodology: Hardware and Software
You should provide information about and the rationale for any hardware or software which will be used to support the project’s research methodology, which is additional or exceptional to conventional desk-based research and institutional provision. They should be included in the Justification of Resources and cross-referenced if there is an associated budget line. Where necessary you should produce additional justification of the use of such items.
You must write ‘Not applicable’ if this section is not relevant to the type of digital output or digital technology proposed.
D. Technical Plan, Section 2.c. Technical Methodology: Data Acquisition, Processing, Analysis and Use
You should provide information about the process of technical development, showing how the standards and formats described in section 2.a and the hardware and software described in section 2.b relate to each other. You must show that you have considered how you will achieve your digital output or digital technology in practice, including issues of timetabling.
You should consider the technical development process from the point of data capture or data creation through to final delivery (in the case of a digital output) or analysis (in the case of a digital process). You should consider issues such as backup, monitoring, quality control and internal documentation where relevant, identifying procedures which are appropriate to the research environment. For example Technical Reviewers acknowledge that the backup procedures which are possible during fieldwork might be very different to those which are possible within an office environment.
This section needs to relate to the timetable and milestones given in the Case for Support as well as the project’s overall research methodology. The Technical Reviewer will be assessing the alignment of the technical development process with other project activities for logic and timeliness.
E. Technical Plan, Section 3. Technical Support and Relevant Experience
You should provide information about the relevant expertise, including examples, of all individuals, facilities, organisations or services that will be responsible for the technical components of your project.
You should identify which aspects of the technical work will be undertaken by these project participants, identifying key individuals where possible. It should be clear to a reviewer that you have access to the appropriate skills and expertise that will deliver a successful project.
In your assessment of risk, under 'Project Management' in the Case for Support, you should consider the risks to the project if a key individual becomes unavailable, including the contingency plan for acquiring these skills from elsewhere.
You are encouraged, wherever appropriate, to seek partners from outside your institution to cover the technical elements of the project, and/or to seek relevant external advice. The key consideration is that your project should be informed by the right level of technical expertise in conception, development and execution. You should provide information about any external advice which you have sought.
You must identify the need for any additional training or expertise and give information as to how this will be provided.
In order to reduce risk to project development and sustainability, and unless there are good reasons not to do so, it is generally wise to ensure that the technical expertise employed by your project is supported by expertise in your institution or one that is a partner to the project. You should show how far this is the case.
The expertise and experience of the participants responsible for the project’s technical components - whether internal or external to your institution - must be evident from the quality of the Technical Plan as a whole. Applicants who claim to be able to draw upon considerable expertise, but are unable to show that they have worked closely with the relevant project participants in completing the Technical Plan, will not be viewed favourably by Technical Reviewers. Similarly, it is unacceptable to state that these participants will address technical issues during the course of the project and then fail to provide sufficient technical detail in the Technical Plan.
F. Technical Plan, Section 4: Preservation, Sustainability and Use
This section contains two separate sub-sections, on preservation and sustainability. The AHRC's definitions of these terms are distinct and not interchangeable.
- Preservation means the storage of a project’s digital outputs for a period beyond the end of funding
- Sustainability refers to your plans for ensuring that digital outputs remain publicly accessible and usable for a period beyond the end of funding. In the case of on-line resources this means keeping the full on-line system working.
Preservation of outputs means that they are potentially re-usable, but not necessarily immediately accessible or easy to use. For present purposes digital outputs include all primary research data (derived or ‘born digital’), programming code and related documentation produced by the project and essential to the project’s research outcomes.
You should clearly indicate in this section which digital outputs of your project will be preserved and which sustained and for what length of time. It is essential to appreciate that there is a cost for preservation and an even greater one for sustainability that will go on beyond the lifetime of the grant. You should note that AHRC awards cannot cover any direct costs relating to the expenditure occurring after the end date of the grant, though they can cover appropriate costs of preparation and ingest of digital outputs that are incurred within the funding period. It is important therefore to consider and outline how the costs incurred after the end of the grant will be funded.
If your project will produce digital outputs that you do not consider worth preserving or sustaining, you should explain and justify this in this section. As a matter of good practice, however, projects are normally expected at least to preserve digital outputs essential to their research outcomes, with a view to supporting these outcomes if necessary, and to the potential value of the outputs for other researchers.
The AHRC requires a minimum of three years after the end of project funding for both preservation and sustainability, but in many, if not most, cases a longer period will be appropriate. This should be decided on the basis of the significance of the outputs in the context of your project, their potential value to the larger research community, and the cost of developing them within the project award. Reviewers will need to be assured that the proposed period of preservation or sustainability represents value for money.
The AHRC normally expects digital outputs that are preserved and/or sustained to be freely available to the research community. Where sustainability plans are made, you must provide justification if you do not envisage open public access for data and open-source status for software that you create or develop; you may make a case for charging for or otherwise limiting access and it will be considered on its merits, but the default expectation is that access will be open. Where digital outputs are preserved but not sustained, the expectation is that they should be freely available on request, but again a case may be put forward to the contrary and will be considered on its merits.
Finally, when completing this section, you should consider the opportunities for re-use of your outputs if appropriate by other resources and web services with a view to increasing their overall impact within the academic and non-academic communities. Examples of opportunities for re-use might include linked datasets for integrated searching across multiple research resources or ingestion into systems and services which are able to add further value and reach new audiences.
G. Technical Plan, Section 4.a. Preserving Your Data
Preservation of digital outputs is necessary in order for them to endure changes in the technological environment and remain potentially re-usable in the future. In this section you must state what, if any, digital outputs of your project you intend to preserve beyond the period of funding.
The length and cost of preservation should be proportionate to the value and significance of the digital outputs. If you believe that none of these should be preserved this must be justified, and if the case is a good one the application will not be prejudiced.
You must consider preservation in four ways: what, where, how and for how long. You must also consider any institutional support needed in order to carry out these plans, whether from an individual, facility, organisation or service.
You should think about the possibilities for re-use of your data in other contexts and by other users, and connect this as appropriate with your plans for dissemination and Pathways to Impact. Where there is potential for re-usability, you should use standards and formats that facilitate this.
The Technical Reviewer will be looking for evidence that you understand the reasons for the choice of technical standards and formats described in Section 2.a Technical Methodology: Standards and Formats.
You should describe the types of documentation which will accompany the data. Documentation in this sense means technical documentation as well as user documentation. It includes, for instance, technical description, code commenting, project-build guidelines, the documentation of technical decisions and resource metadata which is additional to the standards which you have described in Section 2.a. Not all types of documentation will be relevant to a project and the quantity of documentation proposed should be proportionate to the envisaged value of the data.
H. Technical Plan, Section 4.b: Ensuring Continued Accessibility and Use of Your Digital Outputs
In this section you must provide information about any plans for ensuring that digital outputs remain sustainable in the sense of immediately accessible and usable beyond the period of funding. There are costs to ensuring sustainability in this sense over and above the costs of preservation. The project's sustainability plan should therefore be proportionate to the envisaged longer-term value of the data for the research community and should be closely related to your plans for dissemination and Pathways to Impact.
If you believe that digital outputs should not be sustained beyond the period of funding then this should be justified. It is not mandatory to sustain all digital outputs. While you should consider the long-term value of the digital outputs to the research community, where they are purely ancillary to a project’s research outputs there may not be a case for sustaining them (though there would usually be a case for preservation).
You must consider the sustainability of your digital outputs in five ways: what, where, how, for how long, and how the cost will be covered. You must make appropriate provision for user consultation and user testing in this connection, and plan the development of suitable user documentation.
You should provide justification if you do not envisage open, public access. A case can be made for charging for or otherwise limiting access, but the default expectation is that access will be open. The Technical Reviewer will be looking for realistic commitments to sustaining public access in line with affordability and the longer-term value of the digital output.
You must consider any institutional support needed in order to carry out these plans, if not covered under Section 3, as well as the cost of keeping the digital output publicly available in the future, including issues relating to maintenance, infrastructure and upgrade (such as the need to modify aspects of a web interface or software application in order to account for changes in the technological environment). In order to minimise sustainability costs, it is generally useful that the expertise involved in the development of your project is supported by expertise in your own or a partner institution.
A sustainability plan does not necessarily mean a requirement to generate income or prevent resources from being freely available. Rather it is a requirement to consider the direct costs and expertise of maintaining digital outputs for continued access. Some applicants might be able to demonstrate that there will be no significant sustainability problems with their digital output; in some cases the university’s computing services or library might provide a firm commitment to sustaining the resource for a specified period; others might see the benefit of Open Source community development models. You should provide reassurances of sustainability which are proportionate to the envisaged longer-term value of the digital outputs for the research community.
When completing this section, you should consider the potential impact of the data on research in your field (if research in the discipline will be improved through the creation of the digital output, how will it be affected if the resource then disappears?), and make the necessary connections with your Impact Plan. You must factor in the effects of any IP, copyright and ethical issues during the period in which the digital output will be publicly accessible, connecting what you say with the relevant part of your Case for Support.
You must identify whether or not you envisage the academic content (as distinct from the technology) of the digital output being extended or updated beyond the period of funding, addressing the following issues: how this will be done, by who and at what cost. You will need to show how the cost of this will be sustained after the period of funding ends.
Reviewing the Technical Plan
Technical reviewers will comment specifically on the technical feasibility of your proposal and the technical review will also be forwarded to the Principal Investigator together with the peer reviews as part of the PI response stage, to assist the panel in arriving at its grading decisions.
You should also note the AHRC’s requirement, as a condition of award, relating to the availability of significant electronic resources. Please refer to the Research Councils’ Terms and Conditions’ of awards for further details (see Grant Conditions).