We use some essential cookies to make this website work.
We'd like to set additional cookies to understand how you use the Government Project Delivery website, remember your settings and improve government services.
Together with the functional standard for project delivery, it sets expectations for programme and project data management across government.
Functional standards contain both mandatory and advisory elements, described in consistent language (as shown in Table 1).
Table 1: Explanation of terms
Term
Definition
shall
denotes a requirement: a mandatory element
should
denotes a recommendation: an advisory element
may
denotes approval
might
denotes a possibility
can
denotes both capability and possibility
is/are
denotes a description
The meaning of words is as defined in the Shorter Oxford English Dictionary, except where defined in the ‘Project delivery glossary’.
It is assumed that legal and regulatory requirements are always met.
1 About this standard
1.1 Purpose
This programme and project data describes how programme and project delivery data shall be created and maintained across government programmes and projects.
It sets expectations for organisations when defining, formatting and updating programme and project data.
Where organisations create programme and project data relating to data entities and data attributes within this standard, the requirements and definitions set out in this document shall be followed.
This standard applies to all programmes and projects undertaken within or across government departments and their arm’s length bodies.
It covers work at all levels and all delivery methods, from:
programmes and projects listed in the government major project portfolio (GMPP) through to smaller initiatives
digital, infrastructure, transformation, service delivery, military capability, property, regulatory compliance or other purposes
Other public sector organisations may find this standard useful.
1.2.1 Programme and project delivery data
This standard sets requirements for fundamental programme and project data. This is the data that teams use to plan, manage and control programme and project work.
Programme and project delivery data is made up of data entities.
A data entity a main category of information about the work of a programme or project.
Each data entity has several data attributes that help identify, describe or measure it in detail.
This version of the standard covers the data entities most used by project delivery professionals across government.
The in-scope data entities are:
project features
risk
issue
milestone
benefit
cost
people
1.2.2 What is not included in this standard
This standard does not:
describe the specific data to be generated during the life cycle of a programme or project
include data entities or data attributes relating to portfolios, assumptions, change control, dependencies, stakeholder engagement, or quality in programme and project environments
create new reporting obligations for organisations
require organisations to create unnecessary programme or project data
require organisations to use a specific or single project management software or IT solution
require organisations to hold and manage compliant data in a single location
1.2.3 Updates and changes in scope
The quality and scope of this standard will be assessed on an on-going basis. New versions are published following consultation.
Any assessment and revision of this standard will consider:
whether the data being standardised supports the delivery of publicly funded programmes and projects
whether the standard improves the quality of data across government and supports better insights
whether the standard continues to meet the needs and capabilities of the UK project delivery profession
Each version will replace the previous version, while keeping the same purpose and intent. Versions include a clear version number, release date, and a summary of key changes and with the reasons behind them.
Updates are shared via existing Government Project Delivery and National Infrastructure and Service Transformation Authority (NISTA) communication channels. Previous versions will be archived for reference and audit purposes.
1.3 Related standards and guidance
This standard complements and references other government functional standards and guidance.
1.3.1 Government functional standard for project delivery
‘Government Functional Standard GovS 002: Project delivery’ sets expectations for the direction and management of portfolios, programmes and projects ensuring value for money and the successful and timely delivery of government policy and business objectives. It applies to portfolios, programme and projects undertaken within or across government departments and their arm’s length bodies.
1.3.2 The Teal Book
‘The Teal Book’ serves as the core and definitive reference on how project delivery should be done in government. It supports the functional standard for project delivery and provides descriptions of the activities and techniques involved in planning and controlling the work.
The following chapters and sections of The Teal Book are relevant to the requirements set out by this standard:
Chapter 16: Planning supports the creation and use of data within the milestone entity
‘Government Functional Standard GovS 003: People’ (GOV.UK) requires that prevailing human resource process flows, data standards and data definitions shall be adhered to, to ensure understanding of the workforce, data convergence, interoperability and streamlined reporting and decision making across organisations.
The programme and project data standard helps organisations’ programmes and projects meet the requirements of the functional standard for people by defining fundamental attributes for the people in programme and project environments.
1.3.2 Government functional standard for digital
‘Government functional standard GovS 005: Digital’ (GOV.UK) requires that data quality be assessed against 6 dimensions. These 6 dimensions are listed below along with an indication of how the Government subject-specific standard: programme and project data supports them.
6 dimensions
Completeness – ensuring that all required records and essential values are present. This standard provides guidance on the fundamental attributes of each data entity.
Uniqueness – reducing duplication of records. This standard requires organisations to use of unique identifiers for data entities.
Consistency – avoiding contradictions between related data points. Attribute definitions and validation rules in this standard help maintain logical relationships between data points.
Timeliness – keeping data current and relevant. This standard sets minimum update frequencies for each attribute to support up-to-date data.
Validity – ensuring data is in the correct format and within expected ranges. This standard provides formats and category lists to guide data entry.
Accuracy – aligning data with reality. This standard helps reduce ambiguity and supports verification by promoting common definitions and formatting requirements.
The ‘NOVA Functional Reference Model’ (GOV.UK) is a digital repository of leading practice to support the optimal design of back office operations for finance, human resources (HR), grants management and commercial functions.
1.4 Requirements set by this standard
1.4.1 Complying with this standard
Government Project Delivery considers an organisation to be fully compliant with the standard when its in-scope programme and project data is entirely defined, formatted and updated according to the attribute requirements set out in the standard.
The path to full compliance will vary depending on each organisation’s unique programme and project data environment, which is made up of IT systems, data management practices and data maturity. In some cases, limitations of organisations’ programme and project data environments may mean immediate compliance is impossible. When such limitations exist, organisations shall develop implementation plans to overcome them and to work towards full compliance.
1.4.2 Planning for compliance
Implementation plans describe the changes and activities needed in the organisation to enable programmes and projects to create and manage data in line with the standard.
For some programmes and projects, the nature or scale of the project work may mean that not all in-scope data entities and attributes are necessary to plan, control or report on the work. Such programmes and projects are not expected to meet the requirements of this standard.
This subject-specific standard complements the functional standard for project delivery. It sets the minimum data requirements that shall be met by programmes and projects when defining, formatting and updating programme and project delivery data.
Accounting officers are accountable for how information and data are managed in their organisation. Chief data officers are responsible for ensuring that there are clear expectations for managing data and ensure compliance with data and security requirements, including those set by this standard. The senior officer accountable for project delivery in an organisation is responsible for ensuring that the organisation’s programme and project data complies with the requirements of this standard.
For each portfolio, the portfolio director, and for each programme or project, the senior responsible owner ensures that programme and project delivery data is created and managed according to this standard.
In programmes and projects, the senior responsible owner acts as the data owner, with ultimate accountability for the data created by their programme or project team.
Data stewards manage the quality of specific data entities within their programme or project. Anyone in a programme or project team can act as a data steward.
3 Attribute requirements
Each data attribute includes the following elements:
Attribute ID – a unique alphanumeric reference used to identify the attribute. This helps users track versions and refer to specific attributes
Attribute name – the name given to the field.
Definition – a short description of the data that would be captured by the relevant attribute.
Format – how the data shall be recorded and appear. For example, the data may be text or numeric.
Update Frequency – how often the data shall be reviewed and updated. Actual update frequency for project delivery data should be determined by the relevant data steward in consultation with their data owner.
Example – a sample entry of what data recorded against the given attribute may look like. The examples provided reflect accurate applications of this Standard.
Related standard ID – existing data standards from other functions across government that relate to the attribute. The IDs provided here are stored in ‘NOVA Data Dictionary v3.2’ (GOV.UK).
Consistent use of these entities and attributes will help project and programme teams track progress more easily, compare how programmes and projects are performing, and make better decisions using high-quality data.
Data attributes are arranged by data entity.
Where an attribute uses the ‘plain text, category’ format, its list options are provided immediately following the table.
3.1 Project features
The project features entity helps to identify and describe government programmes and projects.
‘Project / Programme ID’, ‘Lead organisation’, and ‘GMPP status’ help facilitate departmental and cross-government comparisons and insights of project and programme performance. ‘Project / Programme ID’ also links project delivery data to a given programme or project and ensures that every entity of project delivery data can be connected in a clear and consistent way.
Table 2 sets out the data attributes that make up the project features entity.
Table 2: Data attributes for the project features entity
Attribute ID
Attribute name
Definition
Format
Update Frequency
Example
Related NOVA functional data standards IDs
GPD_1002_S_001
Project / Programme ID
Unique alphanumeric code used to identify the programme or project.
Text
Once
HMTPROJ0001
HMG_S_68
GPD_1002_S_002
Project / Programme name
A unique, brief title used to refer to the programme or project.
Text
Once
Project Gigabit
HMG_S_69
GPD_1002_S_003
Parent ID
The Project / Programme ID of the Parent Project or Parent Programme, if applicable.
Text
Once
HMTPROJ0001
HMG_S_204
HMG_S_205
GPD_1002_S_004
Child ID
The Project / Programme ID of the Child Project or Child Programme, if applicable.
Text
Once
HMTPROJ0001
HMG_S_202
HMG_S_203
GPD_1002_S_005
Lead organisation
The name of the primary government organisation delivering the project.
Plain text, Category
Once
Department for Environment, Food and Rural Affairs
GPD_1002_S_006
Project category
A categorical indication of the primary domain of the programme or project.
Plain text, Category
Once
Infrastructure and construction
HMG_S_71
GPD_1002_S_007
GMPP status
A categorical indication of whether the programme or project belongs to the Government Major Project Portfolio.
Text
On change
Yes
GPD_1002_S_008
Project start date
The date the project begins. This date should be the beginning of the Feasibility Stage of the project and should follow the conclusion of the Policy Stage.
Date
Once
YYYY-MM-DD
HMG_S_28
GPD_1002_S_009
Project end date
The date on which the project will end. This date should be the end of the Operation Stage and precede Operations.
Date
Quarterly
YYYY-MM-DD
HMG_S_28
GPD_1002_S_010
Programme director name
The name of the Programme Director.
Text
On change
Ben Salisbury
GPD_1002_S_011
Senior responsible owner name
The name of the Senior Responsible Owner.
Text
On change
Ben Salisbury
3.1.1 List options
Project category
For data attribute GPD_1002_S_006, choose from:
‘Infrastructure and construction’
‘Military capability’
‘Digital and data’
‘Transformation and service delivery’
‘International’
The Teal Book (10.3) sets out the categories programmes and projects fall under.
The risk entity contains attributes that support the identification, assessment, ownership, response planning, and monitoring of risks.
‘Risk ID’, ‘Risk title’, ‘Risk type’, ‘Risk cause description’ and ‘Risk event description’ attributes help define and categorise risks clearly.
‘Inherent risk likelihood score’, ‘Inherent risk impact score’, ‘Inherent risk rating’ and their current and residual counterparts support quantitative assessment and tracking over time.
‘Risk proximity’ helps understand when a risk might occur and how quickly it could affect objectives.
‘Risk response category’, ‘Risk response description’, ‘Risk response owner’ and ‘Risk response due date’ support planning and accountability for mitigation actions. ‘Risk owner’ and ‘Raised by’ ensure governance and traceability.
Table 3 sets out the data attributes that make up the risk entity.
Unique alphanumeric code used to identify the risk and its associated data.
Text
Once
PRJ1_RISK001
GPD_1002_S_013
Risk title
A brief summary to identify the risk.
Text
Once
Inclement weather
GPD_1002_S_014
Risk type
Indication of whether the risk is a threat or opportunity.
Plain text, Category
Once
Opportunity
GPD_1002_S_015
Risk cause description
A description of the events or situations that are not risks in themselves but act as sources and drivers for potential risks and can be internal or external to the portfolio, programme or project.
Text
On change
Caused by <event or situation>
GPD_1002_S_016
Risk cause category
A categorical indication of the area in which the risk cause may arise.
Plain text, Category
On change
Strategy
GPD_1002_S_017
Risk event description
A description of an occurrence or change of circumstances. This can be something that is expected that does not happen, or something unexpected that does happen. Events can have multiple causes and impacts and can affect multiple objectives
Text
Once
X may occur
GPD_1002_S_018
Risk event category
A categorical indication of the area in which the risk event could occur.
Plain text, Category
Once
Governance
GPD_1002_S_019
Risk impact description
A description of the effects of the risk on the objectives of the portfolio, programme, project or work package should the event occur.
Text
On change
…resulting in <impact on the objectives>
GPD_1002_S_020
Risk impact category
A categorical indication of the area that would be impacted by the risk event.
Plain text, Category
On change
Security
GPD_1002_S_021
Risk proximity
A categorical indication of how soon the risk is expected to occur from the date of assessment.
Plain text, Category
On change
Imminent
GPD_1002_S_022
Inherent risk rating
The result of the Inherent risk likelihood score multiplied by the Inherent risk impact score.
Numeric
Once
20
GPD_1002_S_023
Inherent risk likelihood score
An indication of the likelihood of this risk occurring (on a scale of 1-5, 5 being certain)
Numeric
Once
4
GPD_1002_S_024
Inherent risk impact score
An indication of the impact should this risk occur.
Numeric
Once
4
GPD_1002_S_025
Current risk rating
The result of the Inherent/ Current risk likelihood score multiplied by the Inherent/ Current risk impact score.
Numeric
Monthly
20
GPD_1002_S_026
Current risk likelihood score
A numerical indication of the likelihood of this risk occurring (on a scale of 1-5, 5 being certain).
Numeric
Monthly
4
GPD_1002_S_027
Current risk impact score
A numerical indication of the impact should this risk occur.
Numeric
Monthly
4
GPD_1002_S_028
Residual risk likelihood score
A numerical indication of the likelihood of the risk occurring after the risk response has been applied.
Numeric
On change
5
GPD_1002_S_029
Residual risk impact score
A numerical indication of the impact, should the risk occur after the risk response has been applied.
Numeric
On change
3
GPD_1002_S_030
Residual risk rating
The residual risk likelihood score multiplied by the estimated residual risk impact score following successful and complete implementation of selected risk response(s).
Numeric
On change
15
GPD_1002_S_031
Risk response category
Whether to avoid, treat, transfer, accept, share, exploit (etc) the risk.
Plain text, Category
On change
Exploit
GPD_1002_S_032
Risk response description
A description of the action required to manage the risk in line with the risk appetite.
Text
On change
To <risk response category> this risk, we will <description of actions>
GPD_1002_S_033
Risk response owner
Name of the individual responsible for implementing the selected risk response.
Text
On change
Ben Salisbury
GPD_1002_S_034
Risk response due date
The date by which the risk response should be carried out.
Date
On change
YYYY-MM-DD
GPD_1002_S_035
Risk owner
Name of the individual with the accountability and authority to manage the risk.
Text
Once
Ben Salisbury
GPD_1002_S_036
Raised by
Name of the person or body who identified the risk
Unique alphanumeric code used to identify the issue and its associated data.
Text
Once
PRJ1_ISS001
GPD_1002_S_038
Issue event description
Description of the issue at a level of detail where it can be managed effectively (such as at work package or project level).
Text
Once
X has occurred
GPD_1002_S_039
Issue cause
A description of the specific factors that caused the event to occur or the query/ concern/ change to be identified.
Text
Once
Caused by <event>
GPD_1002_S_040
Issue cause category
A categorical indication of the area in which the issue cause lies. For issues that are escalated from risks, the Issue cause category could relate to the risk cause category.
Plain text, Category
Once
Governance
GPD_1002_S_041
Issue effect
A description of the effects of the issue on the objectives of the portfolio, programme, project, or work package.
Text
Once
resulting in <effect>
GPD_1002_S_042
Issue impact category
A categorical indication of the type of impact the issue is having.
Plain text, Category
Once
Governance
GPD_1002_S_043
Issue identifier
The name of the person or body who has raised the issue.
Text
Once
Ben Salisbury
GPD_1002_S_044
Issue owner
Assignment of person/persons to management of event.
Text
On change
Ben Salisbury
GPD_1002_S_045
Issue response description
A description of the corrective action/response required to address the issue.
Text
Once
This issue will be addressed through <response>
GPD_1002_S_046
Issue status
A categorical indication of the status of the issue.
The benefit entity defines the attributes relating to a programme or project’s benefits data. These attributes support the consistent definition, monitoring and reporting of benefits across the life cycle.
‘Benefit ID’, ‘Benefit title’, ‘Green Book benefit category’, ‘Green Book benefit class’ and ‘Beneficiary group’ support clear benefit definition and classification.
‘Performance measure’, ‘Realisation start date’, ‘Realisation end date’ and ‘Full-year value’ attributes support tracking and reporting over time.
Table 5 sets out the data attributes that make up the benefit entity.
Unique alphanumeric code used to identify the benefit and its associated data.
Text
Once
PRJ1_BEN001
GPD_1002_S_049
Benefit title
A brief summary to identify the benefit.
Text
Once
Reduced Waiting Times for Public Services
GPD_1002_S_050
Benefit description
A brief summary of the benefit including enabling programme, project or activity.
Text
Once
A digital booking system will reduce waiting times for council services by allowing citizens to schedule appointments online, improving access and efficiency.
GPD_1002_S_051
Green Book benefit category
A categorical indication of the Green Book Benefit Category to which the benefit belongs. Benefit Categories indicate where the benefit is realised.
Plain text, Category
Once
Direct public sector
GPD_1002_S_052
Green Book benefit class
A categorical indication of the Green Book Benefit Classification to which the benefit belongs. Benefit Classes indicate how the benefit is measured.
Plain text, Category
Once
Monetisable
GPD_1002_S_053
Benefit owner
Name of the person responsible for the benefit.
Text
Once
Ben Salisbury
GPD_1002_S_054
Related business case objective
The title of the related objective outlined in the relevant business case.
Text
On change
Improve citizen access to council services through digital transformation.
GPD_1002_S_055
Related strategic objective
The title of the strategic objective to which the benefit relates.
Text
On change
PRJ1_BEN001 aligns with <objective>.
GPD_1002_S_056
Full-year value of the benefit (forecast)
The forecast monetary figure of the full-year value of the benefit in £m.
Numeric
On change
1000
GPD_1002_S_057
Full-year value of the benefit (actual)
The actual monetary figure of the full-year value of the benefit in £m.
Numeric
On change
1000
GPD_1002_S_058
Realisation start date
The date on which the benefit will begin to be realised.
Date
On change
YYYY-MM-DD
GPD_1002_S_059
Realisation end date
The date on which benefit realisation is complete.
Date
On change
YYYY-MM-DD
GPD_1002_S_060
Benefit realisation time frame
The number of years over which the benefit will be realised. This is the difference between the Realisation start date and Realisation end date.
Numeric
On change
3.5
GPD_1002_S_061
Beneficiary group
A categorical indication of the stakeholder group to whom the benefit will be of value.
The milestone entity defines the attributes relating to a programme or project’s milestones. These attributes support consistent planning and monitoring by capturing both planned and actual milestone dates, and milestone types.
‘Milestone ID’, ‘Milestone planned date’, ‘Milestone forecast date’ and ‘Milestone actual date’ support progress monitoring, slippage identification, assurance and reporting.
These attributes support a structured and reliable view of delivery progress and enable effective tracking against baselined schedules.
Table 6 sets out the data attributes that make up the milestone entity.
Unique alphanumeric code used to identify the milestone.
Text
Once
HMT_PROJ0001_M001
GPD_1002_S_064
Milestone title
A brief summary to identify the milestone.
Text
Once
Service Go Live
GPD_1002_S_065
Milestone planned date (baseline)
Initial date on which the milestone is planned to complete. This is the baseline date and should not change.
Date
Once
YYYY-MM-DD
GPD_1002_S_066
Milestone forecast date
The date on which the milestone is currently expected to complete. This should be the date currently in use internally within the project.
Date
On change
YYYY-MM-DD
GPD_1002_S_067
Milestone actual date
The date on which the milestone was completed.
Date
Once
YYYY-MM-DD
GPD_1002_S_068
Milestone category
Categorical indication of which area the milestone belongs to.
Plain text, Category
Once
Assurance
GPD_1002_S_069
Milestone status
Categorisation of the delivery status of the milestone.
Plain text, Category
On change
On track
GPD_1002_S_070
Milestone description
A description of the milestone that adds detail beyond the Milestone Title.
Text
Once
The service becomes live for all registered users.
GPD_1002_S_071
Milestone critical status
Yes/No indication of whether the milestone is on the project’s critical path.
Plain text, Category
On change
Yes
GPD_1002_S_072
Milestone restricted status
Yes/No indication of whether the milestone should be treated as Official-Sensitive.
Plain text, Category
On change
Yes
GPD_1002_S_073
Milestone protected status
Yes/No indication of whether the information provided for this Milestone should be prioritised for protection during centralised reporting.
Plain text, Category
On change
Yes
GPD_1002_S_074
Milestone comment
Text to support understanding of the milestone.
Text
On change
This milestone superseded two archived milestones: <milestone IDs>.
3.4.1 List options
Milestone status
For data attribute GPD_1002_S_069, choose from:
‘On track’
‘Off track’
‘Completed’
‘Superseded’
Milestone category
For data attribute GPD_1002_S_068, choose from:
‘Assurance’
‘Delivery’
‘Business case’
Milestone category list definitions
If your milestone relates to a NISTA Gate
Choose: Assurance
Examples:
NISTA Gate 0 (Programme level)
NISTA Gates 1 to 5 (Project level)
If your milestone is about project delivery dates or critical path
Choose: Delivery
Examples:
project start date (must match project features)
project end date (must match project features)
business case end date (if applicable)
operational end date (if applicable)
any critical path milestones
If your milestone is about a business case
Choose: Business case
Examples:
any HM Treasury business case from strategic outline case to final business case (including revisions)
any HM Treasury programme business case (including revisions)
If your milestone is for GMPP GRIP reporting
Choose: Assurance
Action:
Refer to GMPP Reporting Guidance for GRIP users for details.
3.6 Cost
The cost entity is made up of attributes that help teams monitor costs at different levels — monthly, annually (by the financial year) and over a whole-life period.
Using these attributes enables consistent collection, updating and reporting of cost data. To help report on financial status over time, the data for the cost attributes below should be created with reference to existing finance data standards.
Table 7 sets out the data attributes that make up the cost entity.
The cost/benefit profile approved by the department nearest to the current reporting period. Report in nominal terms. If not available, return nil. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_077
HMT approved estimate
The most recent cost/benefit profile approved by HMT nearest to the current reporting period. Report in nominal terms. If not available, return nil. Input values in £m.
The cost of actual expenditure, accruals and estimated costs to complete the work to the end of the Financial Year. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_083
Current budget (Financial Year)
The agreed cost of the project or resources needed for the Financial Year to achieve an activity by a set time. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_084
Variance (Financial Year)
Cost comparison between what has been funded and what has been spent in the Financial Year. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_085
Actual cost (Month)
The incurred costs charged to the project account and paid or accrued over the given month. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_086
Agreed funding for current stage
The monetary figure (funding) agreed for the current stage of the project. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_087
Agreed funding for next stage
The monetary figure (funding) agreed for the next stage of the project. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_088
One-off new costs (RDEL)
Monetary figure representing the investment in change – the “one off” project resource costs incurred by undertaking the project until its closure. Input values in £m.
Monetary figure representing the investment in change – the “one off” project capital costs incurred by undertaking the project until its closure. Input values in £m.
Monetary figure representing ongoing resource expenditure needed to maintain/service the asset implemented during the project. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_091
Recurring new costs (CDEL)
Monetary figure representing ongoing capital expenditure needed to maintain/service the asset implemented during the project. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_092
Recurring old costs (RDEL)
Monetary figure representing resource expenditure ongoing prior to commencement of the project, recorded only if included in the Business Case. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_093
Recurring old costs (CDEL)
Monetary figure representing capital expenditure ongoing prior to commencement of the project, recorded only if included in the Business Case. Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_094
Non-govt spend (RDEL)
Monetary figure representing resource expenditure met other than from HMT (public finances). Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_095
Non-govt spend (CDEL)
Monetary figure representing capital expenditure met other than from HMT (public finances). Input values in £m.
Numeric
On change
10000
–
GPD_1002_S_096
Departmental baseline year
The financial year of the departmental baseline (Year zero – Y0). Dates should begin with 01/04.
Date
On change
YYYY-MM-DD
HMG_S_28
3.7 People
The people entity is made up of attributes that describe a programme or project’s people data. These attributes support workforce planning, role clarity, capability mapping and governance in programmes and projects.
Attributes such as ‘Current headcount’, ‘Total approved FTE’ and ‘Total public sector employees funded to work in project team (FTE)’ help teams understand the scale and structure of their workforce.
‘Total current vacant post carried (FTE)’ and ‘Total vacant posts carried (12 months) (FTE)’ support forward planning and recruitment tracking.
Data on external contractors and project delivery roles enables visibility of delivery capacity, supports assurance, and informs decisions on resourcing models.
Table 8 sets out the data attributes that make up the people entity.
The total number of employees employed by the project.
Numeric
On change
25
HMG_S_229
HMG_S_583
GPD_1002_S_098
Total approved FTE
The total number of approved positions for the project, as determined by organisational headcount controls.
Numeric
On change
27
HMG_S_229
GPD_1002_S_099
Total funded public sector employees (FTE)
The total number of full-time equivalent civil servants/crown personnel approved for the project team (as agreed in the most recent, relevant business case).
Numeric
On change
100.5
HMG_S_40
HMG_S_583
HMG_S_12
HMG_S_219
GPD_1002_S_100
Total public sector employees in post (FTE)
The total number of full-time equivalent civil servants/crown personnel currently in-post in the project.
Numeric
On change
100.5
HMG_S_40
HMG_S_583
HMG_S_12
HMG_S_219
GPD_1002_S_101
Total current vacant posts carried (FTE)
The total number of approved full-time equivalent positions that are yet to be filled, including civil servants, crown personnel, contracted, and contingent employees.
Numeric
On change
2
HMG_S_40
HMG_S_12
GPD_1002_S_102
Total vacant posts carried (next 12 months) (FTE)
The total number of approved full-time equivalent positions that are unfilled but are planned to be filled within the next 12 months, including civil servants, crown personnel, contracted, and contingent employees.
Numeric
On change
4
HMG_S_40
HMG_S_12
GPD_1002_S_103
Total project delivery posts (FTE)
The total number of full-time equivalent posts in the project team which align with the project delivery profession, either named within the Project Delivery Capability Framework or other project delivery-specific roles.
Numeric
On change
15
HMG_S_229
HMG_S_583
HMG_S_12
HMG_S_219
GPD_1002_S_104
Current contracted and contingent employees (FTE)
The total number of full-time equivalent contracted and contingent employees currently in-post in the project team.
Numeric
On change
5
HMG_S_40
HMG_S_219
4 Metadata
Metadata provides information about other data. For project delivery data, metadata would explain, for example, when a Milestone comment was last updated and who modified it. Metadata is often created automatically by project management software and tools and does not require data creation by users. Metadata can exist for all project delivery data and plays a critical role in supporting data quality.
Table 9 defines a set of common metadata attributes that should apply across all data entities.
The most recent date on which the data was updated.
Datetime
On change
YYYY-MM-DD hh:mm:ss
GPD_1002_M_003
Closure date
The date on which the entry was closed.
Date
Once
YYYY-MM-DD
GPD_1002_M_004
Created by
The name of the person who created the data.
Text
Once
Ben Salisbury
GPD_1002_M_005
Modified by
The name of the person who modified the data.
Text
On change
Ben Salisbury
5 Data validation rules
Data validation rules are checks that make sure data is accurate, consistent, and follows the requirements set out in this standard. They help confirm that information is entered in the right format, uses the correct categories, and meets logical requirements.
These rules work alongside the attribute requirements and metadata guidance in the previous sections. While attributes define what data to capture and metadata explains how to track changes, validation rules ensure that both are applied correctly and reliably.
Table 10: Data validation rules
Validation rule
Description
ID
‘Project / Programme ID’, ‘Risk ID’, ‘Issue ID’, ‘Milestone ID’, ‘Benefit ID’ shall be unique across the organisation.
ID data should be of consistent length and format. So, in the ‘Project / Programme ID’ attribute, if data is entered for a project ID, all project IDs in the organisation must follow the same format and character length.
Numeric format
All numeric fields (for example, ‘Inherent risk rating’) shall be positive numbers unless specified otherwise.
Category validity
Fields with predefined categories (for example. ‘Risk type’, ‘Milestone status’) shall match the list options provided.
Risk rating calculation
‘Inherent risk rating’, ‘Current risk rating’ and ‘Residual risk rating’ shall be equal to their respective likelihood multiplied by the impact scores.
Risk to issue transition
If ‘Current risk likelihood score’ is equal to 5, the risk shall be reclassified as an issue.
Milestone date logic
Milestone actual date shall be on or before today’s date.
Project date logic
‘Project end date’ shall be later than ‘Project start date’.
Benefit realisation logic
‘Realisation end date’ shall be on or after ‘Realisation start date’.
Metadata consistency
‘Last modified’ shall update when any attribute changes; ‘Created by’ and ‘Modified by’ shall be valid user identifiers.
Foreign key integrity
‘Project ID’ shall exist in all related entities (for example, ‘Risk’, ‘Issue’, ‘Milestone’, ‘Benefit’, ‘Cost’, ‘People’).
Date
Shall be stored as per the ISO 8601 standard (iso.org) but may be stored in the system or database proprietary format.
Shall be transmitted as per the ISO 8601 standard ‘YYYY-MM-DD’.
Should be displayed as ‘DDMMYYYY’, but can be displayed as ‘DD/MM/YYYY’ or ‘DD-MM-YYYY’.
See cross-functional data standard HMG_S_28.
Datetime
Shall be stored as per the ISO 8601 standard but may be stored in the system or database proprietary format.
Shall be transmitted as per the ISO 8601 standard ‘YYYY-MM-DDTHH:mm:ss’ for Coordinated Universal Time (UTC) time zone or ‘YYYY-MM-DDTHH:mm:ss+HH:mm’ for Coordinated Universal Time (UTC) time zone offset.
Should be displayed as ‘DDMMYYYY HH:mm:ss’, but can be displayed as “DD/MM/YYYY HH:mm:ss” or “DD-MM-YYYY HH:mm:ss”.
Time zone shall default to GMT/BST, but can be amended to a local time zone if required.
See cross-functional data standard HMG_S_28.
6 Glossary
Some terms in this data standard have specific meanings. New terms introduced in this document are defined below.
These terms have also been added to theproject delivery glossary, which includes definitions for other project delivery terms.
data attribute
A specific piece of information about a data entity. For example, in a milestone entity, attributes include ‘Planned date’, ‘Forecast date’ and ‘Actual date’.
data entity
A main category of information about a programme or project. Examples include ‘Risk’, ‘Issue’, ‘Milestone’, ‘Benefit’, ‘Cost’, ‘People’ and ‘Project features’.
data owner
The person accountable for the overall quality and correct use of project data. For programmes and projects, this is usually the senior responsible owner (SRO). They may delegate tasks to a programme or project manager.
data quality
A measure of how well data meets six dimensions: completeness, uniqueness, consistency, timeliness, validity, and accuracy.
data steward
The person responsible for creating, maintaining, and using project data in line with the standard. They ensure data is accurate, complete, and consistent. Any team member can act as a steward for specific data entities.
metadata
Information about other data, such as when it was created, last modified, and by whom. Metadata supports auditability and version control.
