The Trustees of The British Museum Finds Platform Rebuild

Description

Summary of work The British Museum is looking for a web development partner to provide UX design, prototyping, database design and development services for the rebuild of its Finds platform, originally built 20 years ago and requiring updates to meet modern standards. The product vision of the Finds platform is to be a digital platform that allows the effective collaboration among professional archaeologists, archaeology enthusiasts, finders, researchers and the public in the recording, publication and research of all finds of archaeological interest made by the public in England and Wales, with the purpose of enhancing, sharing and preserving archaeological knowledge, and to enable communities a better understanding of their history. This rebuild project is funded by a government grant and has a defined budget to achieve the following main objectives: 1) Streamline the u ser experience of new finds’ recording, reducing friction for Finds Liaison Officers and a community of trained self-recording finders and volunteers. 2) Enhance the platform so it better serves the needs of researchers via new search, data export and mapping functionality. 3) Implement a Treasure ca se workflow and tracking functionality, to give more visibility to the parties involved about the status of their ca se. 4) Improve the look and feel, accessibility, robustness, and information structure of the public website to make it more appealing and accessible to the public and more manageable and effective for internal staff. The goal of this project is to rebuild the Finds platform, including frontend and backend code, and database changes. The main tasks in scope identified by the BM in the initial discovery are: - rebuilding the existing database - migrating the existing data - ensuring that the website and database services are hosted on scalable infrastructure and responsive to demand - creating new UAT and development environments - putting in place a dditional support for the platform - rebuilding workflows for recording and publishing finds made by the public - rebuilding the database search functionality - rebuilding the data export and sharing functionality - rebuilding the workflows to manage u sers in compliance with GDPR - building dynamic u ser permissions and access control, so that admins can create new u ser roles more easily - building a new workflow to record and track progress of Treasure ca ses, currently managed outside Finds - implementing new logged in dashboards for to-do list (queue) management by different u sers - migrating the current content management functionality to a single content management system - include support for Welsh language content - modernising the look and feel and usability of the finds.org.uk website, bringing it in line with the design guidelines of the BM and highlighting the partnership element of the PAS - improving the navigation and information architecture of the site - implementing workflows to do bulk changes and data imports - improving data visualisation tools (mapping) - Implementing SEO and improving reporting capabilities We are expecting to have long-term support of the platform after the build, post-implementation support including new features, bug fixes and maintenance. Where the supplied staff will work No specific location (for example they can work remotely) Who the organisation using the products or services is PAS operates via a digital platform called Finds to record archaeological finds made by the public in England and Wales, it is managed by the BM in England, and by AC-NMW in Wales. It is a partnership project involving over 100 national and local organisations in England and Wales and includes at least 70 staff employed by local organisations. Why the work is being done The Finds platform (also known as the PAS database) was first built 20 years ago and requires technology updates to meet modern standards. Finds (accessible via www.finds.org.uk) is the main mechanism by which archaeological finds made by the public in England ad Wales are recorded and made available to researchers, Historic Environment Record (HER) officers, and the general public. The recording of finds made by the public is voluntary, unless the find is potential Treasure under the Treasure Act 1996, in which ca se the reporting becomes a legal obligation. The British Museum has a legal mandate to manage Treasure ca se valuation in England and Wales under the Treasure Act of 1996. More than 1.6 million objects have been recorded in Finds, with more than 17,000 Treasure ca ses reported via the Scheme. At least 1,000 research projects, both in the UK and internationally, have used Finds data, and over 1.7 million unique visitors have visited the Finds website in the past 3 years, with an average of 7,500 u sers per week during the last year. The Finds platform carries technical debt, has an outdated u ser experience and look and feel, and is currently under code freeze as the British Museum does not have the internal resources needed to perform these updates in a costly manner. The British Museum obtained a government grant to achieve this rebuild and has a defined budget and timelines to meet the project must be completed before November 2025. Apart from rebuilding and modernising the existing functionality, there is the need to bring a dditional features into the platform that relate to Treasure ca se management, which currently sits outside the Finds platform. Finds depends on a SQL database, the scripts for which can all be found on the application’s public GitHub repository: findsorguk The relational database structure for Finds application is normalised and is hard to model due to the sheer size of the tables used. Over 175 tables are interlinked and cross referenced to drive the MVC architecture of the application layer. Each table has annotated notes attached to it describing its purpose and indexes are in place where tables are joined. These have been optimised to the highest degree possible but the system has been built up in stages over time and the database structure needs to be refactored to fit within a more cohesive architecture. Every table on the database has auditing metadata for date created, created by, updated and updated by, created by and updated by on each table are linked by foreign key to the primary key of the u sers table. Two models of the database are included as appendices to this RFP pack: a full model, and a partial model that strips back the database structure to the primary data tables that drive the recording of object   - Artefacts (non-coins) - Coins - Findspots - Hoards - People The business problem The main challenges of PAS identified so far are: - The Finds platform sits on aging technology that is time cons uming to maintain and modify to meet new requirements - Treasure ca ses are currently managed in Excel spreadsheets with no ability for u sers to track the progress of their ca se without contacting the staff. - Find Liaison Officers are currently overwhelmed by the amount of finds that get reported and are unable to cope with the volume of recordings in a timely manner, which subsequently causes frustration among finders and may discourage the public from reporting new finds. - Finders are very protective about the information on the precise geolocation of finds (findspot), which is critical for archaeological research purposes and for HER officers, therefore guardrails need to be in place to prevent the publication of full findspots to the public. - The relationship between the archaeological and metal detecting communities is much better than before the PAS existed, albeit historical tensions can resurface. The PAS is an attempt to bring these communities together in the benefit of historical knowledge. - Some finders feel that there is little feedback on what the PAS does with their finds records and the results of research, this feedback loop could encourage more recording and engagement with the detecting community. - Researchers do extensive external data cleansing and use other data visualisation software outside Finds to analyse the data, not a practical way to feedback or propose potential changes to the Finds data, potentially leaving data outdated. - The search functionality is clunky and outdated, forcing researchers to contact members of staff to extract data effectively - The data export functionality is not up to modern standards (API led and using Linked Open Data) - u ser permissions are rigid and it is difficult to create new u ser roles as the Scheme evolves - The website is difficult to navigate, it is hard to find what one is looking for - The find recording u ser experience is outdated and difficult to understand for new recorders - The look and feel of the website is outdated and misaligned with the new brand guidelines of the British Museum - Data visualisation within the platform is limited, forcing researchers to export the data and use other platforms for even basic analysis This project will be run in 2 phases, using Agile methodology where appropriate throughout: Phase 1) Finalise Discovery 1a) UX design and prototyping UX and UI design services to outline the new information and content structure of the website, as well as wireframing and prototyping of the u ser interface to begin u ser testing and collection of u ser feedback. The British Museum has a set of digital UI guidelines to adhere to, but the project needs adjustments to these guidelines to reflect the partnership nature of the PAS. The British Museum will provide requirements gathered from stakeholders to inform the creation of scenarios, u ser stories and so on the consultant will be expected to engage with u sers. The outcome of this package of work will include more detailed u ser stories, acceptance criteria and a design scheme for the Finds service. 1b) Database design Database analysis and design services to provide recommendations on the data migration, database architecture, data export functionality including the possibility of a public API, performance, and database search functionality improvements. 1c) Hosting architecture scoping Currently, the Museum hosts the Finds platform on 4 Microsoft Azure VMs running Ubuntu which are supported by a small internal team of developers. The consultant should recommend suitable solutions for the hosting of services, exploring the benefits and drawbacks of a PaaS approach. The Museum will supply technical information, usage statistics and other relevant metrics to help determine the range of best-fit solutions. Phase 2) Build and Testing The Build and Testing phases are expected to be timeboxed to one year altogether and delivered in an Agile manner with incremental iterations according to a set of requirements for an MVP. These phases will need a team of front end, back end, database developers and QAs to redevelop and test the platform. The British Museum’s internal team can assist with UAT tasks. The precise scope of services for Phase 2 onwards will be determined in part by the outcomes of Phase 1. For more details on high level functional and non-functional requirements please refer to FINAL Cost sheet and requirements PAS rebuild.xlsx, included in this RFP pack. The people who will use the product or service User type: Finds Liaison Officer (FLO) Definition: Archaeologist in their 20s-30s (70 percent). First job after uni or interns. There are 45 FLOs working for PAS at the moment. Finds is not popular at university, difficult to recruit. There are a few older FLOs, some of them have changed careers and became archaeologists. Some of them start as volunteers. Full time employees of a partner institution (e.g. Museum of London), trained by the British Museum and Find Advisors. Work under pressure and at capacity to record all the finds reported by the public, record at least 1000 records per year. Being a finds recorder is their core role. Daily u sers of the platform. Finders would contact the FLO that is closer to their home, however this might not necessarily be the FLO closest to the find (especially for finders that go on rallies). Use their discretion to choose what to record based on experience and knowledge, normally done on a first come first served basis, but they find the need to prioritise, as they are shown more finds than they can practically record. They also rely on their network, the PAS Forum, HERs and literature to analyse finds they haven’t seen before. They are encouraged to liaise with self-recorders and volunteers to reduce the bottleneck. They find that some finders are very knowledgeable and are better than others at self-recording finds. They are also encouraged to stay on top of the ongoing research projects in their area. They meet finders to receive and return finds, use a laptop and other equipment (e.g. weights, callipers, better lighting, scanners) in a quiet environment (office or home) to record finds. Medium level of computer savviness, although older FLOs less so. Findspots are the most important acteristic to record in a find. Appropriate image taking and editing (usually with Photoshop) is important, as well as the recording of dimensions and weight. This is important to identify forgery. They use pictures of previously recorded finds on PAS to identify finds that they might not be very familiar with. They are responsible for building community engagement with PAS, and organise “find days” (which are specific days when finders can bring their finds to the FLO for review, usually on weekends), use social media, organise exhibitions, talks. They often visit metal detecting clubs, although this stopped during the pandemic, and it is only being res umed now. They are the first point of contact when a findspot requires excavation and are responsible for promoting best practice, however they are not excavators and encourage finders to contact archaeologists for this purpose. Sometimes they publish articles in magazines about finds and best practice. User type: Finds Adviser Definition: Senior Archaeologist with period specialisms (e.g. Iron Age, Early Medieval, etc). There are 4 working for PAS: 2 at the BM, 1 in Oxford at the Institute of Archaeology. They train FLOs on how to use PAS. Need to validate entries made by FLOs, but do not have the bandwidth due to training commitments and people management duties, which means that many of the records stay in “Awaiting Validation”. They are moderate u sers of the platform and can act as recorders occasionally. They write publications and make decisions on best practice about recording finds. Sometimes they change best practice when new people start recording things differently and they realise these are better ways to do things. They have more attributions than FLOs in the system, as they can edit any record. The existing clunky search functionality forces them to find ways to best record the data in order to facilitate search. There are differences between objects vs coins in terms of terminology (e.g., Medieval period spans different dates depending on the object being recorded), which causes disagreements and is a challenge. There is no Bronze Age specialist at PAS, making it the most difficult period for terminology. They are mostly concerned about the quality of the data entered on the database. User type: Finder Definition: Mainly metal detectorists (MDs) by hobby, field walkers, gardeners. MDs are mostly middle class, employed, white middle-aged men plus wives and girlfriends. There are more than 35k in the UK, and ~65 percent have recorded finds on the PAS database. Most of their finds go unrecorded percent of finders registered with PAS record more than 30 percent of finds on the PAS database. There are currently ~33k registered finders in PAS, but about ~2,700 use the platform occasionally to view their finds. They do not record finds directly on the platform (unless they have been trained to do so) but liaise with FLOs to get their finds recorded. Active MDs go metal detecting every weekend, when the soil is not dry (between Sept-Apr mostly), they do it as a form of exercise, to get out of the house and for fun. There are several types of MDs: independent, belonging to metal detecting clubs and rally MDs. They are represented by the National Council for Metal Detecting (NCMD) and the Federation of Independent Detectorists. Some of them have a passion for archaeology and would love to have been archaeologists if they have had the opportunity. MDs that work in a specific area, know about the landscape and have more knowledge about its archaeology, than detectorists that travel far (e.g., for a rally). They need to get permission from the landowner for their activity (metal detecting is banned in some countries in Europe). The landowner and the MD can get rewarded if the find is deemed Treasure. There are MDs that engage in illegal activities li ke “Nighthawking”, but these are unli kely to record finds on the PAS and are criminals who tarnish the reputation of responsible MDs. Some MDs find it hard to record data as meetings need to be in person with the FLO. They work during the week, therefore cant meet on the week and not all FLOs can meet on the weekend. If the weather is good, they prefer to go detecting on the weekends, so if the FLO organises a Find Day on a weekend with good weather, they might get no shows. They use GPS technology to identify the findspots’ 12-figure National Grid Reference (NGR), they also use “what3words” and longitude and latitude. Some need help from the FLO to identify the NGR. The NCMD has developed an app for finders that is helpful with finding findspots, but this app is not connected to any database. Some of them build strong relationships with their FLOs, but sometimes this relationship can be conflictive, especially because FLOs are busy. Some of them decide to become self-recorders because they can’t get hold of their FLO. They are very protective of their findspots. Some of them have been doing this for years and have a network of people that helps them investigate and record their finds. Some people think that the trust between FLOs and metal detectors has been lost for historical reasons, the relationship between archaeologists and metal detectors was very poor in the 70s and 80s. Generally, not very tech savvy (some of them struggle with email), although this has been improving over time. Some of them are reluctant to record their finds at all with the PAS, as they don’t trust the scheme with regards to maintaining the secrecy of findspots. Some of them find that the PAS Forum can be too political and needs moderation, they normally follow several Facebook metal detecting groups and use these to discuss their finds. User type: Researcher Definition: Academic, student or qualified member of the public who use the PAS database for research. Academics or students from universities, other museums, research institutions from the UK and worldwide. They publish articles about research using PAS data and can sometimes have recording abilities. At least 1,000 research projects have used PAS data. We currently have 275 active researchers registered on the platform. Computer savvy and knowledgeable in statistics. They struggle to download the data as there is a max of 12,000 records that can be downloaded at a time via CSV and sometimes columns go missing on the downloads, removing this limit would be a huge benefit. CSV is a good format, as it can be then transferred to R for statistical analysis. R is very popular among archaeological researchers, and Python has also become more popular over time. They have access to full find spots, but don’t get access to personal details. They don’t see red or quarantine records. They also struggle with the lack of metadata and paradata for the PAS database. Metadata is the explanation of what the data means. Paradata is the explanation on the processes to record the data (e.g. bulk uploads, changes in recording practices, etc). Even though PAS uses FISH vocabulary, it uses its own rationale for term choices, which is not documented and not obvious to non-PAS staff. They are mostly interested in the of data and data visualisation (e.g., clusters of finds, heatmaps). It would be useful for them to not only see where finders have found objects, but also where they have searched and haven’t found anything. The current search is more akin to an old paper catalogue in a museum and not in line with modern digital technology. They would li ke to see every find recorded instead of prefiltered finds from FLOs, because they dont have capacity to record more. There is sometimes problems with mis categorisation of objects or mistakes, which they can amend on the database one by one, but there is no functionality for changes in bulk, which sometimes prevents them from amending records for practical reasons. Ideally, classification and subclassification fields should be downs and ideally there should be a way of creating new classifications and subclassifications. They also sometimes amend periods, dates, spatial data, or materials. The ability to do bulk uploads should be approved by Find Advisors before performing the change. User type: HER Officers Definition: County Council officer using PAS data to update HER records (mostly manually in different separate systems) for build planning purposes. There are ~80 HEROs around the country, with 60 registered in the platform. They have ability to bulk download data from PAS, however the specific CSV template used by HERs doesn’t seem to download seamlessly. They have access to full findspots but no personal records in PAS. They can see who has recorded the record and the second identifier. 50 percent of them use custom built systems li ke HBSMR (from Exegesis) and 50 percent use other more generic Geographic Information Systems (GIS) li ke ArcMap or QGIS to record PAS data. They are not allowed to publish online the full findspots on their platforms, even though they can record them on their systems. This causes sometimes problems, as it is hard for them to give evidence to the public in planning s. They are mostly interested in the of finds for a particular location, as they can lead to investigations of a monument (e.g., a medieval market). In West England, the level of detail in PAS is beyond the level they need, but the most important acteristic is the full findspot. However, in East Anglia they are interested in object descriptions and the object information, not only findspots. They need to do a fair amount of data cleansing to the data to their systems, but these transformations are very specific to the region they work on. Different HERs have different definitions of time periods which were created before FISH (which is the vocabulary used by PAS). They do updates once a month and look for records that haven been updated since then using Advanced Search. They are moderate u sers of the platform. Most of the u sers of HER data (60-70 percent) are commercial archaeology companies which issue assessments for building permissions, the rest are individuals, universities and local groups. Most of the enquiries are about locations, rather than artifacts (e.g., people are interested on the finds on and around a particular location). Universities don’t necessarily have a close relationship with HERs. FLOs have good relationship with HERs in the East of England, but not a close relationship in the West. Amongst the missing functionality on PAS, they have highlighted that the most important one is (especially HERs using GISes) an API (Web Mapping Service) to be able to extract a layer to visualize findspots on their GIS without to do it manually. User type: Treasure Registrars Definition: British Museum and National Museum Wales staff mainly. One Senior Treasure Registrar (Ian Ridson), 4 Treasure Registrars, 1 Treasure Registration Manager in the BM. In Wales, there is one curator that handles most of the Treasure s and there are plans to hire a full member of staff for Treasure. Treasure team staff collaborate with curators, coroners, FLOs, the DCMS, scientific and conservation teams to progress Treasure s. Prepare s to be evaluated by the coroner and manage the valuation process (commission independent valuation experts, prepare meetings, share minutes, etc). They manage this legal process on an excel spreadsheet, during the pandemic they stopped using a specific Treasure database (TAS) due to problems accessing remotely. At the moment they have occasional use of the platform, but the intention is to move them away from the use of spreadsheets into the platform, so the Treasure process can be better tracked by other teams, the public and the DCMS. We expect them to be active u sers of the platform once onboarded. There are ~1,000 treasure finds per year in England and ~100 in Wales, evaluated in s, which take 1-2years to close due to the long process that involves many parties. Not all Treasure finds are acquired by Museums (probably 50 percent), and most (90 percent) are acquired by local museums instead of the BM. If the BM decides to acquire a find, then the DCMS Treasure team would manage the valuation of the object. They must have ability to amend and change records. User type: Museum Curators Definition: They are occasional u sers of the platform. They are museum staff that evaluate Treasure finds for the BM and the local Museums to assess whether these finds are worth acquiring. They are specialised in the particular object type or period. If a find is acquired by their museum, it would go to the respective museum’s collection and can be managed as part of this collection by the curators. Many of the finds by PAS contributors are not on permanent display, but occasionally can be lent or used by the owner museum for exhibitions. User type: Volunteers There are 130 volunteers that have been trained by PAS, most of them coming from the PASt Explorers programme. Some of them have been recruited by the FLOs. They are moderate u sers of the platform in most s. Definition: They are not finders, they are interested in archaeology, they are not employed by any partner or the BM. They do this as a hobby. Can record information on any finds. They also do this as a start of a career in archaeology. There are 130 volunteers that have been trained by PAS, most of them coming from the PASt Explorers programme. Some of them have been recruited by the FLOs. They are moderate u sers of the platform in most s. User type: Resources Manager and Admins Definition: Set up u sers on the PAS system and provide support to u sers. There are 3 u sers currently holding admin rights. Forms need to be populated to create a u ser (sign NDA and Terms and Conditions), and separate approval needs to be provided for the Forum. They help with creating u sers and organise training. They perform coordination and budgeting tasks, dealing with everything that no one else canwant to deal with. They are active u sers of the platform and have wide access to functionality as superu sers. User type: Public Definition: Some of these create and account and register in PAS as Registered members. We have ~19,000 active registered members in the platform. These are occasional u sers of the database. - Landowners – ultimately have the right of ownership on the find and finders need to request permission from them to perform searches on their land. - Field walkers, gardeners, builders discovering things by accident - County archaeologists – they assist with excavations - Countryside advisers – help with by-laws and Countryside Stewardship schemes - Members of public organisations li ke English Heritage, Historic England, Archaeological Societies - Students - Police Any pre-market engagement done A pre-tender market engagement event was held from 2 November 2023 to provide suppliers with more detailed background on the requirements. Work done so far Finds has been live in its current form since 2007 The British Museum has conducted initial discovery of the current state of the platform and u ser needs, documenting these requirements both in Confluence and Jira u ser stories. Approximately 180 product requirements have been gathered and synthesised from interviews, surveys, workshops, analytics, journey mapping and also based on previously gathered requirements by former Business Analysts involved in the project in previous years. All documentation gathered through these exercises can be accessed upon request on the project’s Confluence page and JIRA board. The suppliers team will be expected to work with the internal British Museum Business Analyst, Product Manager and Project Manager, engaging with u sers to refine the final u ser stories for development, prototyping and u ser testing the critical u ser journeys ahead of development. The British Museum will provide access to the different u ser groups and will facilitate interviews, workshops and a dditional discovery activities required. Which phase the project is in Discovery Existing team The existing technology team consists of BM-staff: a Product Manager, Project Manager, two Developers, Head of Technical Services and Lead Technologist. The Head of Technical Services, Developers and Lead Technologist are being involved throughout the project, in the following capacity: - Consultation on product requirements - Review of supplier responses to the RFI and procurement exercises - Clarification meetings with suppliers - Feasibility assessment of proposed software solutions and architecture - Consultation on technical implementation - Code reviews The Product Manager has been hired on a 2-year contract tied to the project funding for PAS. Key responsibilities include: - Oversee the redevelopment of the PAS technical ecosystem from start to finish within an Agile framework. - Collaborate with internal and external stakeholders to ensure the product’s strategic goals are clarified and understood. - Ensure product u ser needs, wants and concerns are captured through consultation and community engagement. - Refine and develop product scope and define formal requirements to support the rebuilding of the product. - Develop u ser stories and redevelop u ser journeys. - Research and analyse market, the u sers, and the roadmap for the product. - Provide product leadership across several disciplines during the consultation, design and build inc. delivery, UXUI, technical. - Assist in the evaluation of external digital software developers and ion of a development partner through a tender process. - Communicate the product vision and direction to the software development team and stakeholders throughout the project. - Create a development roadmap. - Work with strategic technology partners to formulate opportunities for future features and product growth. - Assist in analysing the current PAS data structure with the view to create a roadmap for migration and any data transformation as necessary. - Develop KPIs to measure success. - Manage the product backlog and prioritise based on emerging requirements. - Monitor, test and evaluate product progress at each stage of the project. - Support the coordination of and take part in QA and UAT - Create handover documentation and processes. - Create u ser support material. - Post-implementation support. Project Manager - Lead and coordinate u ser and other stakeholder activities in support of specified projects. - Find strategies to ensure buy-in to deliverables and timetable. - Ensure that accurate, timely and appropriate communications occur. - Plan and manage systems integration activities as required in support of the implementation of key projects. - Support the Product Manager throughout the project. - Manage vendor engagements. - Conduct procurement. - Schedule staff resources. - Administrate the project budget. - Manage project reporting to formal boards and committees on a monthly basis - Ensure that the product is delivered within the timeline, to the required quality. - Produce scoping documents. - Manage project risks Address where the work will be done The British Museum, Great Russell St, London WC1B 3DG Working arrangements The Museum expects to mostly work remotely with the supplier, with the expectation of irregular in-person meetings with internal staff on-site at the British Museum. Most u sers and stakeholders are external and work from various sites around England and Wales. The Museum expects to work in an Agile methodology based on a two-week sprint cadence as well as demos at least every two weeks by the supplier. As a significant amount of custom code will be produced for the Museum with this product, the supplier will be required to share all source code that they produce or use with the Museum on its existing GitHub organisational domain, which is used as the control and collaboration repository for its other development projects. The Museum’s Development team and Lead Technologist will have the opportunity to review all code as it is pushed to the repository. Security and vetting requirements No security clearance needed Latest start date 11 June 2024 Expected contract length Contract length: 2 years 0 months 0 days Optional extension: 1 years 0 months 0 days Budget Indicative maximum: £500000 Indicative minimum: The contract value is not specified by the buyer Further information: Must include support and maintenance fees until the end of the contract. Contracted out service or supply of resource? Contracted out service: the off-payroll rules do not apply Terms and acronyms Term or acronym: PAS Definition: PAS - Portable Antiquities Scheme. The Portable Antiquities Scheme (PAS) is a voluntary scheme to record archaeological finds made by the public in England and Wales. The Scheme is managed by the British Museum in England, and by Amgueddfa Cymru in Wales. Its main objectives are: - Transform archaeological knowledge through the recording and research of public finds, to enable the stories of past peoples and their landscapes to be told. - Sharing new knowledge about archaeological finds made within communities, so that people might learn more about their past, their archaeology and their history. - Promote best archaeological practice among finder communities, so that the past is preserved and protected for the future. - Support museum acquisition of finds made by the public, so that these can be saved for future generations and enjoyed by local people. - Provide long-term sustainability for the recording of new finds, so that these discoveries can contribute to the reinterpretation of our histories. Similar schemes exist in other part of Europe, such as the Netherlands, Finland and Denmark. However, the PAS in England is the most developed and largest in the world. Term or acronym: FLO Definition: Finds Liaison Officer. PAS staff who act as the main point of contact for finders to report finds in their local area. Their main responsibility is to organise public outreach, liaise with finders and record their finds Term or acronym: Recorder Definition: any u ser that is able to create a find record on the Finds platform, they need to request permission and be trained to do so according to the PAS recording principles Term or acronym: Treasure Definition: an archaeological find that meets the profile established by the Treasure Act with regards to its archaeological significance and must be reported within 14 days to a Coroner Term or acronym: BM - The British Museum, AC-NMW - Amgueddfa Cymru (Museum Wales) Definition: BM - The British Museum, AC-NMW - Amgueddfa Cymru (Museum Wales) Term or acronym: HER - Historic Environment Record Definition: HER - Historic Environment Record Term or acronym: TVC - Treasure Valuation Committee Definition: TVC - Treasure Valuation Committee Term or acronym: DPO - Data Protection Officer Definition: DPO - Data Protection Officer Term or acronym: Registered Member Definition: an individual that has created a login to the Finds platform and has activated their account Term or acronym: FISH vocabulary Definition: Thesaurus created by the Forum of Information Standards of Heritage. See www.heritage-standards.org.uk. Controlled vocabulary that enhances the access to cultural heritage information. Controlled vocabulary is a list of terms or classifications with an approval process, sometimes with a hierarchy of terms e.g. tool, axe, hand-axe. Term or acronym: NGR Definition: National Grid Reference number Term or acronym: Findspot Definition: Geographic data for where a find has been found. They are represented in the form of NGR, what3words, longitude and latitude in the Finds platform. Term or acronym: FA Definition: Find Adviser. Specialist in a specific archaeological period andor type of object who oversees the work of FLOs and decides the recording principles on PAS. Term or acronym: ABC - Ancient British Coins. RRC - Roman Republican Coinage. RIC- Roman Imperial Coins. Definition: These are all indexes created by academics to classify coinage in Britain. Term or acronym: DBA Definition: Database administrator Term or acronym: ACM Definition: Assistant Collections Manager Term or acronym: DCMS Definition: Department of Digital, Culture, Media and Sports Term or acronym: NCMD Definition: National Council for Metal Detecting Term or acronym: PAS Forum Definition: Feature of the Finds platform that allows FLOs and metal detectorists to interact and collaborate with each other in online discussion channels. Built using Discourse, open source software. This feature is not in scope to be modified or rebuilt as part of this project, but it is expected to remain as part of the new platform. More about Discourse on www.discourse.org Questions and Clarifications 1. Were assu ming the Azure hosting does not form part of the RFP from a costing perspective? Costs should include fully managed hosting regardless of the hosting provider chosen. Last Updated : <strong>08/03/2024</strong> 2. Will we have regular touchpoints with your internal technical team? Regular touchpoints are expected based on the sprint cadence (at least fortnightly). Last Updated : <strong>08/03/2024</strong> 3. For the 13th March it looks as though the only document to return is Attachment 3, is that correct? Correct Last Updated : <strong>08/03/2024</strong> 4. Do you have any preferences regarding the choice of a content management system, or should we propose one based on the project requirements? We expect the supplier to propose a content management system based on our requirements Last Updated : <strong>08/03/2024</strong> 5. Would to understand the expectation of BM how a bidder should work on Welsh language. The developer would not be responsible for any Welsh-language content, only for implementing support for bilingual content Last Updated : <strong>08/03/2024</strong> 6. Are the functional and non functional requirements the same as the RFI? If so, can you please confirm that we dont need to resubmit these? These have been updated since the RFI, therefore need to be resubmitted as part of this exercise in Stage 2. Last Updated : <strong>08/03/2024</strong> 7. Do you require suppliers to complete the pricing sheet for Stage 1 (March 13th) or as part of Stage 2 (March 27th)? Suppliers may only provide pricing information at Stage 2 Last Updated : <strong>08/03/2024</strong> 8. The Forum functionality is currently on a separate site, are you looking to replace this? Bring this into the overall solution? We are not planning on replacing or altering the current Discourse Forum. Last Updated : <strong>08/03/2024</strong> 9. Are there any specific requirements or preferences for the scalable infrastructure on which the website and database services will be hosted? There are no specific requirements on the hosting provider. Last Updated : <strong>08/03/2024</strong> 10. What database is the data stored in? The data is stored in a MySQL relational database Last Updated : <strong>07/03/2024</strong> 11. Could you elaborate on the data migration process, including any specific challenges or considerations we should be aware of? Please refer to the information supplied in Bid Pack Attachment 1 Statement of Requirements.odt Last Updated : <strong>08/03/2024</strong> 12. What is the volume of data in the database? The three biggest tables are the finds (1.1 million rows), images (870,000 rows) and coin record (530,000 rows) tables. There are 4TB of images approx. Everything else is comparatively negligible in volume. Please refer to the attachments containing the database schema for reference. Last Updated : <strong>07/03/2024</strong> 13. Do you have any estimate on monthly or annual visitor usage? Weve had 335,000 s in the past year, with an average of 40k s per month in the past year .3k per day. Last Updated : <strong>08/03/2024</strong> 14. Have there been any security issues with the site? We have not had any security issues with the site Last Updated : <strong>08/03/2024</strong> 15. Do you have an existing design system for britishmuseum and is it publicly accessible? As per previous question, this is available on Invision and it is publicly accessible. Note that it requires adaptation to the Portable Antiquities Scheme, but can be used as a starting point. Last Updated : <strong>08/03/2024</strong> 16. Could you confirm the only document required for stage 1 is Attachment 3? Correct Last Updated : <strong>08/03/2024</strong> 17. What are the preferred tools or environments for creating new u ser Acceptance Testing (UAT) and development environments? No preference Last Updated : <strong>08/03/2024</strong> 18. Are there any notes or recordings from the pre-tender market engagement event (November 2023) that you can share with us? All the information provided at that event has been incorporated into the information that has been published as part of the opportunity so there is nothing further to share Last Updated : <strong>08/03/2024</strong> 19. Can we see your brand guidelines? Please not that forward slashes may be automatically removed by the CAS platform, we apologise for any inconvenience https:www.britishmuseum.orgsitesdefaultfiles2019-11DesignGuidelines_16Mar2012.pdf Last Updated : <strong>08/03/2024</strong> 20. Attachment 2 refers to instructions to “use this attachment to provide your responses to the Essential and Nice to have criteria”. Can we confirm that it should be Attachment 3 where criteria are given? Correct Last Updated : <strong>08/03/2024</strong> 21. Could you confirm the content and scoring for the presentation stage, and will this be remote or in person Supporting instructions for the presentation will be supplied when Stage 2 materials are published. Last Updated : <strong>08/03/2024</strong> 22. Are we required to complete the FINAL Cost sheet and requirements PAS rebuild spreadsheet as part of our stage 1 submission. We are asing this is not the reading through the documents, but we just wanted to double check. No, it is not needed at Stage 1, but will be needed for Stage 2 which comes soon after Last Updated : <strong>08/03/2024</strong> 23. Can you confirm that the Initial Contract term will be 3 years 1 year implementation, and two years support and Maintenance? Correct. The support and maintenance contract will be re procured at the end of 3 years to secure long term support for the platform Last Updated : <strong>08/03/2024</strong> 24. We are currently answering the Essential and Nice-to-have skills and experience for part 1 of the process and just have 2 questions which would be grateful for your help with. 1. For our answers, we understand that these should be a maximum of 750 acters. Please can you confirm we should write the answers directly under the questions on the word document supplied? 2. Are we able to submit itional information on a separate document to support our answers or should we just submit the answers on the document? You can write the answers in the box provided on the Word document supplied, there is a max of 750 cha racters per question. Please make reference to the question being answered as part of your response. Due to the volume of expected answers, please respect the max 750 cha racters per question on your response. Last Updated : <strong>08/03/2024</strong> 25. In view of the importance of getting the right solution for your unique requirements regarding invaluable national assets given the extreme legacy environment of the data and your stated shortage of internal resource, would you consider (perhaps separately) an independent consultant (divorced from this procurement if necessary) on your team to help you get this right? read your documentation there are a number of areas of concern where our knowledge prompts use to raise a flag to alert you to these, as a socially responsible company. For instance, what you are embarked on is very much the invisible aspect of a knowledge iceberg, which is the most crucial aspect of the solution - plus the area where new technologies and approaches could change your current appreciation of the requirements. Included in this procurement are experience design, database consultancy services and technical design, which should cover all areas of the project as part of the discovery phase. During this phase we have flexibility to adapt these requirements according to recommendations made by the supplier, provided that the solution stays within budget Last Updated : <strong>08/03/2024</strong> 26. Can we see your digital UI guidelines? Please note that forward slashes may be automatically removed from this message by the CAS platform. We apologise for the inconvenience You can access these guidelines here: https:projects.invisionapp.com boards 6Z3TSCR5HKQ https:projects.invisionapp.com share ZHR92H5MUFY screens 357808552?browse Please note that the designs have evolved a bit since, as these date from 2019 Last Updated : <strong>08/03/2024</strong> 27. You note “building dynamic u ser permissions and access control, so that admins can create new u ser roles more easily.” Can you give examples of the sort of u ser roles you may need to create? Please refer to attachment PAS Roles and Permission Matrices for examples. Roles such as Curator, ACM Staff, Other Museum, DCMS, Conservators, Volunteer and Self Recorder need to be created. Other roles exist in the current platform. Last Updated : <strong>08/03/2024</strong> 28. You note “building a new workflow to record and track progress of Treasure c ases” and that this is currently managed in Excel. Can you give an overview of how this workflow currently works? The current workflow works as per Visio attachment Treasure Process v2. The process works via Excel spreadhseets stored in shared folders on the British Museums internal network and communication is managed and coordinated via email by the Treasure Registrars. This prevents visibility of the workflow for any stakeholder who doesnt have access to the British Museums internal network. Last Updated : <strong>08/03/2024</strong> 29. You note product requirements are in JIRA and Confluence, is it possible to grant us read-access to this? JIRA requirements (Functional and non Functional) have been exported on the attachment FINAL Cost Sheet and Requirements PAS Rebuild. Relevant Confluence documentation has been exported to the pack, too. We cannot give read only access to our JIRA and Confluence instances at this stage, but this will be part of the onboarding of the new supplier. Last Updated : <strong>08/03/2024</strong> 30. May we clarify what is meant by experience of developing websites for large communities? For example, would sites aimed at the general public with large traffic be acceptable? Sites aimed at the general public with large traffic, provided that they require u ser interaction with the site besides reading (e.g. via uploading content, or making requests, etc) , are acceptable as examples of this experience. Also it would be acceptable examples of sites that are used by a range of u sers that are part of a large u serbase and have diverse interests or interact in different ways with the platform. Last Updated : <strong>08/03/2024</strong> 31. We note in Attachment 3 there is only one response field for “Essential Skills” and one for “Nice to Have”. Can you confirm that all answers are to be in these respective sections? Correct .You can write the answers in the box provided on the Word document supplied, there is a max of 750 ch aracters per question. Please make reference to the question being answered as part of your response. Due to the volume of expected answers, please respect the max 750 ch aracters per question on your response. Last Updated : <strong>08/03/2024</strong> 32. We think that the formula in the cost sheet 3. Pricing Sheet tab, cell F31, should be (formula deleted by the CAS platform) is that correct? This will be changed when Stage 2 materials are published, well clarify that the pricing sheets ongoing costs cover years 1, 2 and 3 inclusive Last Updated : <strong>08/03/2024</strong> 33. We note that hosting architecture design is part of the initial discovery. Does the British Museum have a preference for hosting, should we price based on our preference? The British Museum has no preference for any particular hosting platform. Please specifically state your preferred hosting provider and price accordingly in your Stage 2 response. Last Updated : <strong>08/03/2024</strong> 34. When may you be able to share volumes on which to base hosting resources Data disk size for the server hosting the production site it is 6144GB. There is a separate training server but this does not store much data, we would expect a UAT server to require roughly the same amount of storage as production. Over the last month, the network traffic to the production server was 590.2GB incoming, .1TB outgoing. For the database server this was 84.7GB incoming and 513.5GB outgoing. For the training server this was 6GB incoming 8.3GB outgoing. We think that the site can be better architected, but as a reference server costs for the financial year 2023 2024 have been approximately £12,000 Last Updated : <strong>08/03/2024</strong> 35. What are the business hours for the SLA? Please note that business hours are UK hours 9.00 to 17.30, Monday to Friday. However, our SLA response and resolution times specified on the requirements sheet are defined based on 24 hours 7 days timelines for hosting, and business hours for other type of issues. Last Updated : <strong>08/03/2024</strong> 36. For the Stage 1 (March 13th) deadline, do we just provide a response to the 20 essential and 9 nice to have skills and experience criteria detailed in Attachment 3? For the above, are we permitted to respond with a maximum of 750 ch aracters per criteria? Correct. You can write the answers in the box provided on the Word document supplied, there is a max of 750 ch aracters per question. Please make reference to the question being answered as part of your response. Due to the volume of expected answers, please respect the max 750 ch aracters per question on your response. Last Updated : <strong>08/03/2024</strong> 37. Can you please provide examples of the types of data visualisation you would the new platform to include. Data visualisation is expected in the form of mapping functionality (e.g. via embedded GIS) as a minimum, with ch aracteristics that allow u sers to visualise the distribution of findspots on a map and also provide the ability to visualise these data points as heatmaps. The map should provide the ability to have multiple layers to visualise the data in the current as well as historical landscape (e.g. Roman Empire). The data should also be available in tabular format, so that two dimensional bar ch arts and line ch arts can be plotted from this data based on find ch aracteristics (e.g. materials). Last Updated : <strong>08/03/2024</strong> 38. Are you able to let us know what a dditional information, and what further assessment documents, will be released to suppliers for Stage 2? Will we have the opportunity to ask further clarification questions after these are released? At Stage 2 we will release supporting materials for presentations and timeslots. As part of the presentations and interviews there will be opportunity for suppliers to pose questions to our team. Last Updated : <strong>08/03/2024</strong> 39. Findsorguk Github looks pretty active still. What is the drive to fully replace this? We only push maintenance patches to the findsorguk repo. We are rebuilding the site to a ddress technical debt and the volume of feature changes required. Last Updated : <strong>08/03/2024</strong> 40. Can you provide more details on the existing Finds platform, such as the current technologies used, challenges faced, and any specific issues that need to be a ddressed in the rebuild? Please refer to the information supplied in Bid Pack Attachment 1 Statement of Requirements.odt Last Updated : <strong>08/03/2024</strong> 41. We assu me the budget mentioned in the RFP is for the entire project duration. Could you share the defined budget for the project go live and the expected timeline for completion? The budget is for development, deployment and the first year of support. We expect the supplier to provide an estimate on the timeline for completion. Based on information gathered at the RFI stage, we expect this project to take no longer than 18 months to implement and go live. Last Updated : <strong>08/03/2024</strong> 42. Do we create a data migration format for the process or BM have any specified format and DB in place. Part of the engagement is database consulting services, which should take care of advising on the format most suitable for our requirements. Last Updated : <strong>08/03/2024</strong> 43. Can you provide more information on the expected level of support required post-implementation, including the frequency of updates, bug fixes, and the process for handling maintenance? This is outlined on the requirements sheet (PR-208) and the attachment PAS SLA overview Last Updated : <strong>08/03/2024</strong> 44. Could you provide more details on the desired functionality of the Treasure c ase workflow and the specific requirements for tracking and visibility? Please refer to Treasure Process v2 (automated processes).vdsx in All visio attachments.zip, and requirements within the Treasure process category in the requirements sheet Last Updated : <strong>08/03/2024</strong> 45. What specific guidelines or requirements should be followed to ensure GDPR compliance in u ser management workflows? Would to understand the existing workflow of the system. Requirements (where known) are outlined on the requirements sheet and will be finalised with our Data Protection Officer during the discovery process. GDPR is an evolving topic, therefore we expect the solution to comply with the latest guidelines from the ICO. Currently, u sers that are onboarded to the platform and require a higher u ser level access are requested to accept Terms and Conditions to the platform and sign Non Disclosure Agreements as part of their onboarding process. The signature of these documents is coordinated by the Resources Manager and is a manual process via email. Last Updated : <strong>08/03/2024</strong> 46. Can you provide specific requirements or expectations regarding SEO implementation and the desired reporting capabilities? Can we go ahead with a partner for the specific task. We expect the supplier to provide the needed analysis and a plan with technical and non technical recommendations to optimise the search for the website on Google based on its u sers search patterns. We expect the supplier to implement the technical recommendations from this analysis. Reporting should be available through Google Analytics and Google Search Console. There should not be a problem to use a partner for this task, provided that the costs are included in the proposal and the supplier owns the relationship with the partner. Last Updated : <strong>08/03/2024</strong> 47. Could you provide more details on the extent of Welsh language content support required for the platform? Do we get the translated content from BM for the language implementation, or do we have to do it from our end. The Museum will provide the translated content to Welsh, the supplier is not expected to translate any content Last Updated : <strong>08/03/2024</strong> 48. What kind of supporting documents BM anticipate getting from bidders to prove their previous experience and expertise in the same. Bidders are encouraged to provide links to projects within their Stage 1 responses, although please be aware that certain special ch aracters (e.g. forward slash) may not be present when submitted to the Contract Award Service platform we cannot accept attachments at Stage 1. Your response should have a max of 750 ch aracters per question. Last Updated : <strong>08/03/2024</strong> 49. Is there any scope of training that is also part of the implementation? We expect training and training materials to be provided for any new interfaces (e.g. CMS) implemented as part of the rebuild so that the internal British Museum team can roll out training materials to the wider u ser group Last Updated : <strong>08/03/2024</strong> 50. We assu me that all the required infrastructure support shall be provided by BM for project deployment. Please clarify in c ase of any deviation. All infrastructure support for the platform, both for development and deployment, should be provided by the supplier Last Updated : <strong>08/03/2024</strong> 51. What are the deliverables to be given by the successful vendor as project deliverables? Any expectations from BM regarding this please share. Please refer to requirements and the tender pack documentation Last Updated : <strong>08/03/2024</strong> 52. Any technology BM willing to proceed with or bidder can propose? We expect the bidder to propose the technology stack most suitable to meet our requirements and according to the budget Last Updated : <strong>08/03/2024</strong> 53. Closing date for- applications 13-03-2024 12:00 and Closing date for written proposals 27-03-2024 12:00 . These are the two things mentioned in RFP would to clarify the 13-03-2024 only the bidder has to share the details for Responses to Essential and Nice to have skills and experience and by 27-03-2024 the ed bidder in Essential and Nice-to-have skills and experience would eligible to submit the technical proposal with all details. Please clarify. Your understanding is correct Last Updated : <strong>08/03/2024</strong>