ADVICE

AHRC logo

AHRC Grant Applicants

Version 3, February 2015

Introduction

In 2012/3the Archaeology Data Service ceased to receive direct funding from the AHRC to enable it to continue its previous services to the archaeological research community. This means that the range of services, training, advice and support that were offered by AHDS Archaeology, and subsequently the ADS, have changed. The ADS therefore no longer offers a technical advisory service to the AHRC, neither does it evaluate the technical appendixes of grant applications. However we remain as an approved digital archive for projects receiving awards.

The ADS no longer accepts digital outputs created by AHRC funded projects for archiving free of charge. For new and current projects, charges will apply for ingest and preservation and should be negotiated prior to application and included in the budgeting of the project. The long term preservation of ADS holdings will continue to be guaranteed by a combination of the appropriate physical security measures and the administrative and managerial procedures associated with them. The ADS charging policy is designed to allow the ongoing costs of long-term preservation to be factored into a single charge at the point of deposit. Consequently depositors can be assured of long-term preservation of their data even where their project is funded on a finite time scale.

The AHRC has stipulated that:

  • Publications should be made available as rapidly and effectively as possible via deposit in an appropriate repository at or around the time of publication. The Archaeology Data Service (ADS) must be consulted within three months of the start of the proposed research and data must be offered for deposit within three months of project completion.
  • Electronic resources must remain accessible for a minimum of three years after the end of the award.
  • A technical plan is required, where digital outputs or digital technologies are an essential part to the planned research outcomes. This should give a summary of those outputs, explain the technical methodology, technical support / experience, and address preservation, sustainability and use.
  • Publications must be made available and accessible for public use as widely, rapidly and effectively as practicable.
  • The AHRC requires that significant electronic resources or datasets are made available in an accessible depository for at least three years after the end of the grant.
  • Details required in the technical appendix cover data creation and sustainability, however there is not a specific mandate to preserve apart from in the case of archaeology. Other grant holders are expected to keep data accessible for three years.

Notes on the Technical Plan

''These notes have been provided by the AHRC and can be found at http://www.ahrc.ac.uk/Funding-Opportunities/Research-funding/RFG/Application-guidance/Pages/Technical-Plan.aspx''

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.

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.

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

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 on-line'.

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.

AHRC Technical Appendix - FAQs

This page provides some Frequently Asked Questions on the AHRC Technical Appendix ''Content created: April 2005 and December 2005 by AHDS staff Content updates: March 2008 and February 2015 by ADS staff''

What is the Technical Appendix or Plan?

Application forms for certain AHRC research schemes include a Technical Plan. Applicants planning to create a digital resource are required to complete a Technical Plan to demonstrate that their project has or will have the necessary knowledge to implement the technical aspects of a project. While the crucial part of any application is its intellectual content, an application that does not pay sufficient attention to the Technical Plan is likely to hinder significantly the chances of receiving funding.

Do I have to write a Technical Plan?

According to AHRC guidelines, if a significant product or by-product of your project is the creation of an electronic resource, you must complete the Technical Plan section. In practice, this includes most types of digital resource. There are some exceptions for minor digital resources (websites that only give information about the project, but do not deliver any digitised materials), but before deciding not to complete a Technical Plan, it is worth contacting the ADS to clarify each individual case.

How long should the Technical Plan be?

The AHRC has implemented electronic submissions and, with the J-eS submission website, there is a character limit on each section of the Technical Plan. The lengths of the limits are advertised on the website responsible for handling electronic submissions. However, additional relevant information may be attached. This may include graphical information, such as Gantt charts, or additional text where character limits on the form do not allow the inclusion of sufficient information. For any questions related to the use of electronic submission, applicants should contact the Joint Electronic Submission Helpdesk.

The word limit in the Je-S system is too short. Can I provide additional graphics or supplementary information?

If, in your view, the word limits or formatting restrictions for any one section do not allow you to include sufficient information, graphical information (Gantt charts, etc.) and additional textual information may be included as an attachment to the proposal.

What additional help is there?

The ADS is happy to read (but not write) technical plans prior to submission. To ensure a full response we should be contacted four to six weeks before the final submission date.

Should I put details on project management in the main part of the application or in the Technical Plan?

The main part of their application should deal with project management in its widest sense, including the many non-technical aspects of a research programme or project, for example how research trips, conferences and print publications will be organised and managed. The Technical Plan, on the other hand, concentrates only on the implementation of the technical part of the project. However, there may well be overlap between the two. In such cases it is permissible to have a smaller project management section that refers back to the main application.

What exactly is a sustainable resource?

'Sustainable' has two overlapping meanings within this context. Technical sustainability of a resource is achieved through the use of recommended formats, good documentation and a suitable preservation strategy; formats and documentation are dealt with in the Plan; the preservation aspect is dealt with in other sections. Operational sustainability deals with the how a resource will continue to be run and managed once the initial funding has ended. While it is not obligatory (and indeed may not be necessary) to have a sustainability plan, awareness of how a resource, particularly larger ones, may be continued in the long-term will help the quality of a Technical Plan . All successful applicants are encouraged to offer a copy of their resource to the ADS. Depositing a resource with the ADS is an excellent way of ensuring a level of technical and operational sustainability.

How can I make my resource accessible?

A project's data (e.g. dataset, text, collection of images) can be deposited with the ADS and the ADS will make that collection part of its digital archive and therefore accessible via the ADS website. The data can then be publicly searched along with all the other resources curated by the ADS. Projects may also wish to develop their own project websites to make a resource accessible. This could involve adding specific search mechanisms or using particular technologies to deliver their digitised material. The development of such websites should be referred to in the Plan. Applicants should use this opportunity to indicate that the website will be 'accessible' in a more precise sense - i.e. that by the use of web standards the website will be usable by different users using different types of Internet browsers. Applicants should note that while the ADS preserves the underlying data it does not currently preserve such website interfaces, although depositors may wish to discuss with the ADS the possibility of a special interface being designed by the ADS to display their datasets. In a small number of circumstances, it will not be feasible for applicants to disseminate their resource via the ADS. In this case, it is possible to discuss other options for deposit with the ADS such as the preservation-only option, where the ADS retains a copy but does not make it available to others. In some very particular cases (such as the development of software), it will not be necessary to deposit a copy of the resource. In such instances, applicants should fill out the Waiver of Deposit form.

I'm not able to clear all Intellectual Property Rights (IPR) / Data Protection issues prior to submission. Does this rule me out?

Applicants can apply for funding for digitisation even if not all copyright or data protection issues have been cleared. However, the Technical Plan must demonstrate that plans are in place to deal with IPR / data protection during the lifetime of the project and that these plans are likely to be executed successfully. Applicants should note that depositing a resource with the ADS does not entail handing over the copyright of that resource to the ADS or the AHRC.

I'm applying for a second tranche of funding. Do I need to write another Technical Plan?

Yes. It is advisable that the successful points of the first part of the project are highlighted in the Technical Plan.

I am experienced in data creation and have already had several discussions with the ADS. Do I need to write a Technical Plan?

Applicants cannot assume that assessors of the Technical Plan will be automatically aware of other work by the applicant. Even if an applicant has good experience of digitisation work, this needs to be demonstrated within the Technical Plan.

I know little about the digital aspect of the application and will be outsourcing the digital work to an outside company. Do I still need to write a Technical Plan?

The Technical Plan still needs to be written. Indeed, any applicant in such a position should ensure they have a satisfactory grasp of the technical aspects of the project. This will allow them to communicate their aims to the outside company and that during the lifetime of the project they will be able to verify that the digital work is being done to the required standards.