Ctrl+K

Quantitative project protocol design

Quantitative project protocol design#

The importance of good protocol design#

A project protocol document allows you and the client to agree on what the focus of the project will be, how the project will be conducted, what will happen in the project and what the outputs of the project will be. This protocol document should act as a reference point for both you and the client. It also allows you to clearly communicate to any other person what the project is. This process is core to transparency, replicability and accountability.

Timing of protocol development#

The protocol document should be produced at the same time as the ethics application is being written. Ideally the protocol should be submitted as a supporting document with the ethics application. One document will support the production of the other.

Information to be included in a protocol#

Overview and rationale#

The first section is a brief overview of the background of the project and the rationale for undertaking the project in the way to be described in the rest of the protocol. This should only be 400-600 words (1 - 1.5 pages). Keeping this section should give the reader enough information to understand the context in which the project is taking place without going into the details.

Project aims and objectives#

Clear and concise project aims and objectives should be provided. The aim or aims should be over-arching and capture the broad focus of the project. The objectives should be specific and task related reflecting the delivery of the project.

Research questions#

The research questions need to be linked to an objective. They should be what informs each analysis undertaken as outlined in the analysis description section of the protocol. There should be a clear and explicit link between the objectives, research questions and analyses being undertaken.

Data/sample description#

The data description will most likely be developed with the client/data provider. This section can be taken from or developed into the data request agreed with the client as the data request should contain most of this information and act as a reference point between us and client.

This section will contain information including but not limited to:

  • A description of who or what the data is concerning

  • The time period of the data to be used

  • The data fields being requested/used in the analysis

    • Field name

    • Content description

    • Format (integer, float, string, time-date, category)

  • Any inclusion and exclusion criteria being applied to data

  • Any sampling criteria to be applied to the data before or after extraction

Modelling approach (if appropriate)#

The information required will vary by the modelling approach being employed. In general it should include as a minimum:

  • A brief description of the model to be built

  • The modelling method being used, the programming language being used and the packages being used with the implementation

  • A rationale for the modelling method being used

  • A table of the model input parameters and the data being used from the data description to create these parameters

  • A table of the expected model outputs. This should align with the data required in the analysis description

  • A description of the model build process including:

    • Parameter creation

    • The model development process

    • The model validation process

    • The collation of the model outputs

Analysis description#

The analysis description should detail for each analysis to be performed:

  • A brief description of the analysis

  • The research question the analysis is being used to answer

  • The analysis method being used and a brief rationale for its use

  • The variables being analysed

  • The analysis outputs being collated

  • The visualisation method to be used

Outputs#

A list of outputs from the project should be provided. The outputs section of this document provides information on the minimum outputs recommended from a project and information on other ‘good to have’ outputs.

The minimum recommended outputs from a project are:

  • A project report produced as a Jupyter Book

  • A GitHub repository containing all of the project code and the project report

  • A DOI for the GitHub repository produced using Zenodo

Contents