Summary Recommendations

13.2 The table below lists the summary recommendations with the paragraph(s) numbers on which they depend.

Number 

Recommendation

1

We recommend that, where it is necessary to choose between heritage ICT projects, the selection should be carried out in the following order of priority:

  • where the project can diminish risk of loss of a heritage asset, such as through survey and record;
  • here the project can aid conservation and preservation;
  • where the product of the project will itself be a heritage asset;
  • where the project meets HLF education and access policy objectives; and
  • where opportunities exist for public participation in the creation of new resources, or the retroconversion or digitisation of older ones where the result would have public benefit. (¶ 1.5) 
      
The HLF should not fund ICT research and development. (¶ 6.2) 
       
The HLF should not normally fund distribution and access infrastructure (e.g. networks to interconnect institutions).(¶ 6.3) 
      
The HLF should support the creation of digital resources through collection of new data. (¶s 7.1 & 7.2) 
       
The HLF should support the retroconversion or digitisation of material where value is added to the data during the process of conversion, whether this is a by-product of its transfer to digital form or as a direct result of enrichment during transfer. (¶s 7.1 & 7.2) 
       
The HLF should expect heritage organisations to demonstrate in their applications how they propose carrying out the generation of high-level synthesis to make material more understandable. (¶ 7.3) 
        
The HLF should support the use of ICT to create new digital resources of heritage merit, and among projects proposing to do this kind of work a priority should be given to projects which involve community effort in the collection and collation of the data (see ¶s 9.11-9.14 on collaboration). (¶s 7.5 & 7.6) 
        
The HLF should not be nervous about supporting work involving creation of digital records of heritage assets which are not in public conservation management where these materials will encourage and inform conservation, assist public understanding, and provide a record of objects at risk of loss. (¶s 7.5 & 7.6) 
       
The HLF should support the retroconversion of catalogues, inventories, and other analogue information resources used by the heritage sector where the digital version will bring new benefits to the public sector and where the resource has long term value; (¶s 7.7-7.11). 
       
10  The HLF should positively support the use of ICT to permit archival institutions to retroconvert their finding aids to digital form; (¶s 7.7-7.11). 
           
11  The HLF should only support those projects that demonstrate that during retroconversion every effort will be made to add value to the resources being converted; (¶s 7.7-7.11). 
        
12  The HLF should only support digitisation programmes of documents or images at archives which have retroconverted, or are in the process of retroconverting their finding aids; (¶s 7.7-7.11). 
        
13  The HLF should support the retroconversion of habitat and biological records, and archaeological archives. (¶s 7.7-7.11). 
         
14 

The HLF should only support digitisation projects:

  • where the information content is high and significant proven public and educational benefit would result from the conversion;
  • where material is at risk;
  • where the benefit of digitisation is greater than the risk to which it subjects the material being digitised;
  • where the existing storage medium is no longer suitable as a storage medium (e.g. nitrate film, photographic prints);
  • where the methods of digitisation suggest that the digital surrogate might be a preservation medium;
  • where digitisation would significantly increase resource accessibility;
  • where clear (international) standards will be used to facilitate storage, retrieval, and preservation;
  • where ‘rights’ issues (see ¶s 10.11 & 10.12 ) are not a bar to dissemination;
  • as a means of conserving heavily used material;
  • when it will provide material of value to the educational sector; and
  • when it enhances the ways in which the content of collections can be studied, manipulated, or accessed. (¶s 7.12-7.15). 
         
15  The HLF should acknowledge that, in the present state of the technology, digitisation should not be seen as a way to create either a preservation or replacement version except under exceptional circumstances (e.g. where the format of the material is not the most useful, such as printed directories). (¶s 7.12-7.15). 
        
16  In order to ensure that the digital resources created with HLF funding are of a consistently high quality, applicants must detail the active steps they will take to guarantee this quality. (¶s 7.16 & 7.17). 
         
17  The HLF should support initiatives to use ICT to bring consistent data collection and inputting standards to the recording of our heritage assets. (¶s 7.16 & 7.17). 
          
18  The HLF should keep a watching brief on technology trends so that it anticipates and is not surprised by innovative applications of the technology and does not consider run-of-the-mill applications as risky. (¶s 8.1-8.11). 
            
19  The HLF should undertake regular reviews of ICT elements of the projects it funds. (¶s 8.1-8.11). 
            
20  Trustees should consider developing a future programme for innovative applications of ICT in heritage sectors. (¶ 8.12). 
            
21  The HLF should support the development of database applications whether in the form of new content, retroconverted catalogues or records where these resources will be publicly accessible or provide heritage benefit. (¶s 8.13 & 8.14). 
            
22  The HLF should support collaborative ventures between local authorities, companies, and other public bodies to develop resources that will assist the preservation and conservation of our natural or built heritage, and sub-surface archaeological deposits. (¶s 8.15-8.16). 
              
23  The collection of the necessary data should be supported by the HLF where the Virtual Reality model and the data will be publicly accessible. (¶s 8.15-8.16). 
         
24  Simulation systems that support the testing of vegetation coverage patterns of various plant types (e.g. forestry) should be eligible for support. (¶s 8.15-8.16). 
              
25  The HLF should not fund the development or maintenance of institutional Websites and intranets. (¶s 8.17-8.19). 
        
26  Projects receiving HLF support which produce materials in digital form should be required as a matter of course to establish a Web presence as a by-product of their development activities. (¶s 8.17-8.19). 
         
27  The HLF should not fund the development of interactive displays unless they are a by-product of a consistent and coherent information service. (¶s 8.22-8.25). 
        
28  The HLF should not fund interactives unless the applicant has built a clear case that interactive displays meet the criteria of fitness for purpose and use. (¶s 8.22-8.25).
         
29  When the HLF does fund proposals for interactives they should be applications which support and accommodate group interaction (e.g. slave monitors, interfaces for multiple users, communication between different users). (¶s 8.22-8.25). 
          
30  Applicants proposing to develop interactive displays should be required to describe in full the team model which they propose applying and how it will be managed in practice (see ¶s 10.6-10.10). (¶s 8.22-8.25). 
              
31  The HLF should encourage projects which wish to develop interactive displays to do so in collaboration with commercial partners. (¶s 8.22-8.25). 
         
32  The HLF should require that access to all IT-based resources created with its support should be free at some level. (¶s 9.1-9.3). 
         
33  The HLF should accept that all data might not be suitable for general release. (¶s 9.1-9.3). 
         
34  The HLF should accept that charging should be acceptable where the funds are going back into making certain that the resource is sustainable. (¶s 9.1-9.3). 
       
35  The HLF should give preference to ICT projects that harness community spirit and use volunteer labour to collect, collate, and interpret the cultural heritage. Projects based on volunteers should demonstrate that suspension and training of volunteers has been carefully thought-out, as well as checking/control of work produced. (¶ 9.4). 
            
36  The HLF should investigate how it might work with the DTI, and such programmes as IT for All, to improve public access to, and understanding of, ICT through the support of community-based heritage ICT projects. (¶ 9.5). 
            
37  The HLF should encourage the use of ICT to produce content that can support the educational activities of heritage organisations. (¶s 9.6-9.10). 
             
38  The HLF should make certain that any digital resources created with its funds are freely available for educational purposes. (¶s 9.6-9.10). 
            
39  The HLF should develop a working relationship with funding agencies which are supporting pure research to identify areas where synergy is possible.(¶ 9.11). 
           
40  The HLF should work with other organisations such as the DTI and the EU to develop a joint programme supporting projects developing digital resources and multimedia projects that make that content accessible. (¶ 9.11). 
           
41   The HLF should only fund IT-based heritage sector projects which have limited commercial viability. (¶ 9.12).
          
42  The HLF needs to encourage consortia bids. (¶s 9.13-9.14). 
          
43  The HLF should support ‘project-targeted’ ICT training on those IT-based projects it funds. (¶s 9.15 & 9.16). 
          
44  The HLF should not fund postgraduate or professional training programmes. (¶s 9.15 & 9.16) 
           
45 

The HLF should require that applications for ICT projects or for the ICT aspects of larger projects be accompanied by:

  • results of evaluations carried out in the course of the preparation of the application;
  • clearly defined strategies for carrying out formative evaluations and for feeding the results of these evaluations into the development process; and
  • clearly defined summative evaluation plans including proposals for the dissemination of results of these so that they can inform other developments in this sector (¶s 10.1 & 10.2). 
           
46  The HLF should only fund ICT projects where the applicant has demonstrated through detailed risk assessment that all risks are acceptable. (¶s 10.3-10.5). 
          
47  The HLF should require that details of other projects managed by the project team be included with all projects. (¶s 10.6-10.10). 
         
48  The HLF should require successfully that applicants prepare and submit a Project Initiation Document. (¶s 10.6-10.10). 
              
49  The HLF should require projects to establish a set of measurable and accessible milestones comprising a clear deliverable or set of deliverables linked to each milestone. (¶s 10.6-10.10). 
          
50  The HLF should require details of the activities or tasks and resources needed to achieve the deliverable targets. (¶s 10.6-10.10). 
             
51  The HLF should require that applicants seeking support for ICT projects which produce digital resources demonstrate that they have in place suitable strategies to protect their rights in the digital aspects of the materials in their care or that they are creating. A licence agreement might provide a starting point. (¶ 10.11). 
          
52  The HLF should remain appraised of the issues involved in digital preservation with a view to ensuring that resources created with funds it distributes remain viable and usable for coming generations. (¶s 10.13 & 10.14). 
            
53  Applicants should be required to provide evidence of their approach to data preservation. (¶s 10.15 & 10.16). 
            
54   The HLF should investigate the feasibility of supporting a national archaeological data service in conjunction with the statutory bodies, including RCHMs, English Heritage, Historic Scotland, and the HEFCs’ Archaeology Data Service. (¶s 10.15 & 10.16).
          
55  The contract between the HLF and the grantee should be amended to state that the life of digital data is indefinite. (¶s 10.15 & 10.16). 
            
56  The HLF should examine whether there is a genuine need for a data archive to preserve the digital resources being created by the projects it funds. (¶s 10.15 & 10.16). 
            
57  The HLF should require that organisations developing digital data sets produce adequate levels of documentation to make certain that the digital materials they are creating will be understood in the future. (¶ 10.17). 
          
58  The HLF should point potential applicants to standards resources such as those listed in Appendix I but it should not develop its own standards advisory service. (¶s 10.18-10.24). 
            
59  The HLF should not fund the development of standards. (¶s 10.18-10.24). 
           
60  The HLF should require applicants to demonstrate that they have selected standards appropriate to the scale, needs, and objectives of their project and to the heritage sector in which the project originates. (¶s 10.18-10.24). 
           
61  The HLF should require applicants to demonstrate that they have both the technical skills and trained staff to put the selected standards into use. (¶s 10.18-10.24). 
          
62  The HLF should require applicants to provide evidence that they are documenting the data to a standard sufficient to support its long-term preservation and reuse. (¶s 10.18-10.24). 
            
63  The HLF should not be directive about standards, but applicants should document why they have chosen a particular standard and explain their reasoning. (¶s 10.18-10.24). 
            
64  In all cases where data capture, creation, or retroconversion are being carried out, the applicant must provide evidence that the work being done conforms to standards of best practice as currently understood. (¶s 10.18-10.24). 
             
65  All Case Officers should be provided with a two-day training course to introduce them to the main issues of heritage information technology including an overview of current applications and the technological possibilities. In subsequent years they should be provided with a half-day refresher course. (¶ 11.2). 
           
66  Potential applicants should be encouraged to bear in mind that as well as demonstrating the public and heritage benefits associated with the use of ICT in projects, they will need to demonstrate that the project is effectively designed to reduce the risks commonly associated with ICT projects. (¶ 11.3 & 11.4). 
            
67  The HLF should require that all IT-based projects produce at least a project initiation design document before the HLF takes a decision in principle about whether or not to fund the project. (¶s 11.5 & 11.6). 
             
68  Before proceeding to a final funding decision, the applicant should produce a full set of technical documentation. (¶s 11.5 & 11.6). 
        
69  The HLF should adopt a detailed ICT project assessment strategy. (¶ 11.7). 
            
70  The HLF should revise its contract so that it is suitable for ICT projects. (¶ 11.8). 
             
71  The HLF should adopt an audit model for monitoring new ICT projects which relies on using applicant-defined milestones to measure the successful achievement of progress and occasional external visitations. (¶ 11.9). 
            
72  The HLF should undertake post-project appraisal which validates the objectives and outcomes of the project as defined in the business case. (¶ 11.10). 
          
73  All applications containing an ICT element should be considered by an ICT expert before being considered for funding. A risk assessment model should be applied in evaluating all applications. (¶s 11.11 & 11.12). 
         
74 The existing Panel Membership should be extended to include IT-literate professionals. (¶s 11.11 & 11.12).