Core Document Development and Management Guidance

Introduction

Purpose

1. This document provides support to the University community regarding the development of Core Documents at Northeastern University London (the University).

Scope

2. This guidance applies to policies, procedures, forms, strategies, guidance, board/committee terms of reference, and other documentation produced by the University that informs internal and external stakeholders of University operations.
3. This guidance aims to encompass the creation, review, update, approval, and storage of policies, procedures, and supporting documentation.

Definitions

Document Types

4. Core Document: A term used to encompass official University documents including but not limited to strategies, policies, procedures, guidance, forms, templates and terms of reference.
5. Strategy: A strategy is a plan developed to provide direction and action toward achieving a long-term goal.
6. Policy: A policy is an institutional rule or regulation that governs operations. Policies contain overarching principles that guide decisions and establish expectations.
7. Procedure: A procedure is a standardised process for the implementation of a policy.
8. Guidance: Guidance is a set of detailed instructions, resources, and information tailored to a specific audience. Guidance may support the intended audience through a process or utilisation of a service.
9. Form: A form is used to gather information for the purposes of initiating or progressing within a procedure.
10. Template: A template contains standardised content, structure, and formatting, which can be edited to produce an independent document of similar style and layout to related materials.
11. Terms of Reference: Terms of reference define the purpose and operational guidelines of a board, committee, or sub-organisation within the greater community.

Document Sections

12. Appendix: An appendix contains data that cannot be placed in the main document and has references in the original file. Appendices are numbered A, B, C. Appendices are placed before the version control box, with a page break.
13. Annex: An annex is a standalone document that offers additional information. Annexes are numbered A, B, C. Annexes are placed after the version control box, with a page break.
14. Version Control Box: A version control box is a summary of published versions of a document and their associated dates of publication and proposed next review.

Collaboration

15. Drafts folder: The drafts folder contains the most updated version of documents under review or development. The drafts folder is managed by the Quality Team and all changes to documents in the drafts folder must be tracked using Google Docs Suggesting mode.
16. Editing mode: Editing mode is a setting in Google Docs that replaces the content of a document without changes tracked. Editing mode is not used for collaboration purposes.
17. Suggesting mode: Suggesting mode is a setting in Google Docs that tracks all edits to documents as suggestions. Suggesting mode assigns a unique font color to each contributor’s suggestions, and all edits are time stamped with a description and the contributor’s login details in the margin.

Roles and Responsibilities

18. Quality Team: The Quality Team is responsible for coordinating the review and update of policies, procedures, and associated documents. The Quality Team maintains historical records, version control, and ensures consistency and cohesion in Core Documents across University departments. The Quality Team provides support and guidance to those tasked with document development.
19. Owner: A document Owner is responsible for document creation and development. Owners are accountable for regularly reviewing and updating documents according to the predetermined update schedule. They are responsible for disseminating approved updates and identifying parties affected by the implementation of newly created or developed Core Documents.
20. Contributor: A Contributor is a member of the University community that plays an active role in the development of documents of which they are not the Owner.
21. Preliminary Reviewer: A Preliminary Reviewer is a Contributor who is delegated by the document Owner to conduct the initial stages of review, consultation, and update of the document.
22. Approver: The Approver is the employee or approving body accountable for final revision and approval of documents prior to publication.

Resources

23. Quality Team: The Quality Team is accessible via qualityassurance@nulondon.ac.uk
24. Published Core Documents are available for reference in the following collections:
    1. Academic Handbook
    2. Staff Handbook
    3. PeopleHR
25. Related Documents
26. Core Document Development and Management Policy and Procedure
27. Template for Policies
28. Template for Procedures
29. Formal Document Style Guide
30. Committee Proposal Form

General Principles

31. This Guidance is to be used in conjunction with the related documents referenced in Resources.
32. Any questions regarding this document or its use should be directed to the Quality Team.

Types of Procedural Documents

33. Common types of Core Documents are listed in Definitions.
34. Documents must be named appropriately to promote accessibility of and clarity regarding the University’s information structure. Likewise, the contents of documents must reflect the title and intended purpose.
35. Documents are often routed through approval and review stages based on their type. Inappropriately named documents may be routed through unnecessary stages of approvals or may not be given adequate consideration through their development.

Version Control and File Naming Conventions

36. The Quality Team follows a strict naming system to track and manage documents. It is essential that Owners and Contributors do not change document titles once initial draft documents have been submitted to the Quality Team for further management.
37. Version control is an essential function of the Quality Team. The Quality Team manages the storage and publication of draft and approved documents. These versions illustrate the exchange, development, justification, and approval or rejection of ideas.
38. Document titles must include the document topic and type (see Definitions for types of Core Documents). See Annex A: Sample File Naming Conventions for descriptions and examples of naming conventions.
39. Version Number
    1. Version numbers consist of three parts, separated by a full stop. As documents are developed and published, version numbers increase.

40. Academic Year
    1. This number refers to the academic year for which this version of the document is first implemented.
    2. The number ‘24’ refers to Academic Year 2024-25, ‘25’ refers to Academic Year 2025-26, and so forth.
    3. As Core Documents are developed and published in advance of an academic year, the Academic Year Version Number is used to inform the University community which document to apply for individual circumstances.
41. Major Version Number
    1. The Major Version Number refers to the number of times the document has undergone Major Modifications (see Categories of Modification for additional details) and been routed through the document’s Approver.
    2. The first approved Major Version Number of a document is 1.
    3. As Major Modifications are approved, the Major Version Number increases by 1 and the Minor Version Number resets to 0 (for example, 23.1.1 > 23.2.0).
42. Minor Version Number
    1. The Minor Version Number refers to the number of times the document has undergone Minor Modifications (see Categories of Modification for additional details) and been approved and published by the Quality Team.
    2. For a newly approved Major Version, the Minor Version Number is set to 0 (for example, 23.1.0).
    3. As Minor Modifications are approved, the Minor Version Number increases by 1 (for example, 23.1.1 > 23.1.2).
43. Draft Status: Documents under development or review are indicated with the word ‘DRAFT’ in the file name. Drafts are developed with all comments and changes tracked. Draft numbers are indicated after the word DRAFT and are written as DRAFT 01, DRAFT 02, DRAFT 03, etc.
44. Governance Consideration Sought: When submitting a document to a committee for consideration, the Quality Team indicates the type of consideration sought in the file name of the document. Common types of consideration sought are to note, receive, discuss, approve, recommend, and endorse.
45. File Format: DOCX and PDF are the file formats used by the Quality Team. Document types are converted according to Quality Team internal procedures.

Categories of Modification

Minor Modifications

43. Minor Modifications provide clarification, or correct typographical or grammatical errors. Minor Modifications may be used to promote accuracy or clarity, but do not inherently alter behaviours or expectations within the University.
44. Minor Modifications can be made at any point during the academic year and are approved by the Quality Team.
45. Examples of Minor Modifications include:
    1. Correction of grammar, spelling, or punctuation in a document, which does not change the approved form, fit or function
    2. Change of titles to reflect approved organisational restructure
    3. Update of term or year that mirrors previously approved timelines
    4. Update of links or references to related documents or sources
    5. Change of formatting or branding that does not affect the content or structure of the document

Major Modifications

46. Major Modifications substantially alter the content of documents. Major Modifications require consultation and Approver support before publication and distribution.
47. Major Modifications require careful planning for successful implementation, which may include additional resources, training, and external distribution.
48. Examples of Major Modifications include:
    1. Change that cannot be classified as a Minor Change
    2. Change of purpose, scope, or procedure
    3. Change that requires training or resources for successful implementation
    4. Change that requires regulatory notification
    5. Change that requires external verification and/or validation

Structure

49. The structure of Core Documents must be consistent across University departments. The sections found within specific document types are listed in Annex B: Document Structure and Sections. This list is not exhaustive, and all sections listed may not apply to all topics.
50. Although section titles of different document types may be the same, they contain information relevant to the purpose and topic of the document. For example, the terms in the definitions section of a policy will likely include regulatory definitions, parties as defined within the policy, and definitions that clarify overarching concepts for the community. In contrast, the terms in the definitions section of a guidance document will likely include specific references to departmental documents, processes, or roles.

Document Suites

51. Document suites are collections of related documents that support one another but serve different functions. Suites often include a policy, procedure, guidance, and forms that facilitate operations regarding a specific topic.
52. Suites are reviewed together as a unit but documents can be updated independently to reflect operational developments, changes in titles, roles, or responsibilities.
53. Content should not be duplicated across the documents in a suite. Instead, references to related documents are listed in Resources and/or in the Version Control Box.

Storage

54. University documents are stored, developed, and shared using Google Workspace applications.
55. Archive: Previous versions of draft, approved, and published documents are archived by the Quality Team. Archived documents must not be edited, deleted, or removed from the archive.
56. Working Drafts: Draft versions are created and shared through Google Docs for the development and exchange of ideas in anticipation of forthcoming updates.
57. Currently Published Documents: The most up-to-date documents are stored by the Quality Team and published on the University website, PeopleHR and Virtual Learning Environment.
58. Core Documents are to be shared via links to published documents on the website, PeopleHR, and Canvas. Word versions of working drafts are not to be downloaded or stored on personal or University computers.

Format

59. The format of Core Documents must be consistent across departments. The Formal Document Style Guide includes guidelines for approved font, spacing, size, margins, bullets, indentations, and other aspects of formatting Core Documents. See Resources for the link to the style guide.
60. During the draft stage, content and organisation of ideas are prioritised. For initial document creation, formatting is usually standardised before routing through committees for approval. For document updates, formatting is usually standardised before publication.

Terminology

61. The terminology of the following must be consistent across University documentation.

Table 1 Approved Terminology

Tone, Tense and Language

62. Documents are written in third person and present tense, using clear and concise language. Refrain from using ‘you’ and ‘your’ in the interest of clarity and formality.
63. Committee minutes and strategic plans may be written in past and future tenses, respectively.
64. Write out numbers up to ten and use figures for 11 onwards. Similarly, spell out first through tenth and use figures for 11th onwards.
65. Common Latin abbreviations are punctuated according to the following table. The English words are to be used where possible.

Table 2 Common Latin Abbreviations

66. Use of a serial comma in lists of three or more items is strongly recommended to eliminate confusion. This serial comma is otherwise known as the Oxford comma, and is inserted before the ‘and’, ‘or’, or ‘nor’ in a series of three or more items.
    1. Incorrect: We went on a walk with our dogs, grandma and grandad.
    2. Correct: We went on a walk with our dogs, grandma, and grandad.

Capitalisation

67. Relevant parties to which the document applies should be capitalised, defined in Definitions, and referenced in title case throughout the document.
68. Sentence case is used for document body and text.
    1. Sentence case looks like this.
    2. In sentence case, the first letter of the phrase is capitalised, in addition to proper nouns and titles.
69. Title case is used for document titles, subtitles, and headings
    1. Title Case Looks Like This.
    2. In title case, the first letter of the phrase, all major words, and all words of four of more letters are capitalised.
    3. Lowercase letters are used for minor words of three letters or fewer such as conjunctions (and, or, nor, but), articles (a, an, the), and prepositions (as, at, by, for, in, of, on, per, to).
70. When referring to a specific term as defined in Definitions, the term is capitalised throughout the document. For example: Document Owners and Contributors must seek approval from the document’s Approver before publication.
71. When referring to terms in general, the term is not capitalised. For example: This Guidance provides instruction and support to those who write guidance documents.

Procedure

72. The procedure for creating and developing documents is linked in Resources. The diagram below illustrates the basic stages of the procedure. Owners and Contributors may be asked to assist with any of the stages indicated below.
73. See the Appendix A: Core Document Development Procedure for a visual representation of the information contained in this section.

Initiation

74. Documents have been developed to satisfy regulatory requirements and capture the University’s operational activities. Before proposing the creation, development, or retirement of documents, Owners and Contributors must have a firm understanding of historical and related documents and their functions. One seemingly small change may impact multiple documents and must therefore be considered by relevant stakeholders.

Proposal

75. Members of the University community may initiate the creation or development of a document. A proposal containing the following should be sent to the Quality Team:
    1. The nature of the proposal, such as the creation of a new document, development of an existing document, or retirement of an existing document.
    2. The justification or rationale for proposed changes, including relevant research, common practice, and legal or regulatory requirements.
    3. An overview of proposed changes, including any changes made since the last submission for approval.
    4. Related documents that may be affected by this proposal.
    5. A proposed implementation plan, including how and when the proposed changes are to be implemented, any training or resources required for successful implementation, and a distribution list and desired publication date, if applicable.
76. The content of this proposal accompanies the document through the development, approval and implementation stages.
77. The Quality Team may recommend additional research and consultation to support the proposal.
78. The Quality Team routes the proposal through consultation and approval stages as needed and, if approved, provides the proposer with a draft version for development or a suitable template for the creation of a new document.

Development

79. Collaboration during the development stage requires timely contribution and open communication across departments. Timelines for collaboration are set to ensure documents are routed through approval(s) and ready for distribution according to the predetermined implementation plan.
80. A strict method of tracking suggestions is employed by the Quality Team to maintain version control and approval or rejection of ideas.
81. Google Drive Collaboration: All comments and suggested changes are tracked using Google Docs.
    1. Working drafts and the DRAFTS folder
       1. Comments and suggestions are made in documents that are stored in the ‘00 DRAFTS under development’ folder.
       2. The location or parent folder of a document saved in the Google Drives can be viewed through File > Document details.
       3. Drafts are not to be downloaded, moved, or copied. Multiple copies and versions of developing documents creates confusion and fragmentation of ideas.
    2. Suggesting mode
       1. Comments and suggestions are made in Suggesting mode in Google Docs. Suggesting mode tracks changes and allows Contributors to work on the same document simultaneously.
       2. Documents automatically open in the Editing mode. Changes are not to be made in any document through the Editing mode. Changes must be tracked from one version to another.
       3. To change from Editing mode to Suggesting mode, click Editing in the upper right and from the drop-down menu, select Suggesting.
       4. In Suggesting mode, any changes made are reflected in a different colour and deleted text is crossed out.
       5. Owners and Contributors must not accept tracked changes in draft documents. If tracked changes are accepted, there is no tracking mechanism to illustrate that a change has been made.
    3. Comments
       1. Comments are used to highlight text for discussion and draw attention to specific sections within a document. Contributors can be emailed a link to the targeted comment by inserting the recipient’s email address after ‘@’ in the Comment text box.

Table 3 Common Google Docs Functions

Approval

82. The approval structure of formal documents mirrors the University’s governance structure. Documents are routed to the Approver along predetermined consultation paths as defined in the reporting structure of the University’s governance diagram and committee Terms of Reference.
83. The Approver of a formal document is indicated in the Version Control Box.
84. Document Owners are responsible for alerting the Quality Team that a drafted document is ready for submission through the approval stage.
85. The Committee Proposal Form must accompany all papers for committee and board consideration.
86. Before submission to the Approver or preliminary consultative groups, the Quality Team prepares the Committee Proposal Form. For resubmissions, Approver feedback is retained from previous drafts and a new Committee Proposal Form is included.
87. The Quality Team includes the proposal description and rationale from the initiation stage and invites the Owner to make amendments as needed prior to submission for Approver review.
88. The Quality Team stores a final draft in the archives and removes editing rights from Owners and Contributors.
89. The Quality Team routes the document through relevant authoritative bodies, based on the University’s routing procedure for approvals and consultative groups. Relevant authoritative bodies are asked to note, receive, discuss, approve, recommend, or endorse the proposal. Authoritative body feedback is classed as one of the following: approved, approved with minor corrections, or revise and resubmit. Feedback from authoritative bodies is sent by the Quality Team to the document Owner as it is received.
    1. If the Approver’s decision is for the Owner to revise and resubmit, the Quality Team routes the draft back through the development and approval stages.
    2. If the draft is approved with minor corrections, a new draft is created and placed in the drafts folder for further development. If the Approver is a committee or board, the Committee or Board Chair may approve the prescribed minor corrections through Chair’s Actions.
    3. If the proposed document is approved, the Quality Team initiates the implementation stage.
90. Feedback may also include action items and expected completion dates, which are communicated to Owners by the Quality Team.

Implementation

91. Successful implementation of new and updated policies and procedural documents requires timely distribution and effective communication.
92. The Quality Team sets the proposed date of next review, updates version numbers, organizes document storage, finalizes formatting, and publishes approved documents on the University website.
93. Owners are responsible for distribution of approved documents and relevant training according to the implementation plan specified in the proposal.

Schedule of Review and Updates

94. Regulatory bodies normally require the University to publish all policies impacting student experience and learning in advance of the academic year to enable them to make informed decisions. Policy Owners are expected to manage reviews, approvals and publication of policies with this requirement in mind.
95. The Quality Team initiates subsequent review of documents according to the proposed date of next review.
96. Any document may be called for review and update outside of the predetermined schedule.

Reporting, Monitoring and Reviewing

97. The Quality Team, document Owners and Contributors review statistical information relating to the Core Document Development and Management Policy and associated procedures on an ongoing basis.
98. The Quality Team tracks the creation, development and management of Core Documents and makes recommendations to the Policy and Compliance Committee and Executive Committee as appropriate.
99. The Quality Team and the Policy and Compliance Committee review this guidance for effectiveness.
     

Appendix A: Core Document Development Procedure

Version History

Annex A: Sample File Naming Conventions

Annex B: Document Structure and Sections

*Optional sections depending on document topic and purpose