Choose a content type for a Government Project Delivery product

Guides help people working in project delivery understand how to approach a specific task or topic.

Use a guide to provide practical advice and steps for any relevant person, written for a general reader rather than specialists, with flexibility in how they apply it to their own context.

Guides are different from handbooks, which provide comprehensive reference material for practitioners who need detailed, specialist information.

When to use a guide

Use a guide when you want to help people:

• understand how to approach a common task or challenge
• get started with something new or unfamiliar

When not to use a guide

Do not use guides for mandatory requirements or processes. Use a standard instead.

Do not use guides for comprehensive reference material that covers everything about a topic. Use a handbook instead.

Do not use guides for detailed step-by-step instructions that must be followed exactly. Use a process or code of practice instead.

Writing a guide

A guide should include practical advice that can be adapted to different contexts, clear explanations written for a general audience, and links to related standards or handbooks where helpful.

Write in second person (‘you should’) and avoid jargon. Focus on helping people understand the approach rather than prescribing exact steps.

Guides are published in the Government Project Delivery product library and can be promoted through news, blogs and events.

Examples

• Quick guide to benefits management in government (requires sign in)
• Achieving inclusive outcomes by design (requires sign in)

Handbooks provide comprehensive reference material that covers everything people need to know about a topic in project delivery.

Use a handbook when you want to create detailed reference material that practitioners can refer to repeatedly for in-depth information and guidance. It should clearly signpost all relevant requirements and support readers on how to meet them. Tools and techniques can be incorporated into handbooks but consider publishing these separately.

Handbooks are different from guides, which provide practical advice for general readers who need to understand an approach rather than comprehensive specialist information.

When to use a handbook

Use a handbook when you want to:

• provide comprehensive coverage of a complex topic
• create reference material people will return to regularly
• bring together all the information someone needs in one place
• explain detailed concepts, processes and considerations

When not to use a handbook

Do not use handbooks for simple tasks that need quick guidance. Use a guide instead.

Do not use handbooks for mandatory requirements. Use a standard instead.

Do not use handbooks for step-by-step processes that must be followed exactly. Use a process or code of practice instead.

Writing a handbook

A handbook should include comprehensive information organised into clear sections, detailed explanations of concepts and approaches, examples and case studies to illustrate key points, and links to related standards, guides and tools.

Consider how your handbook fits within the Teal Book’s structure and chapters, and how it supports practitioners in meeting the requirements set out there.

Use clear headings and structure to help people find specific information quickly.

Handbooks are published in the Government Project Delivery product library and can be promoted through news, blogs and events.

Examples

• Adopting the programme and project data standard
• Role of the senior responsible owner
• Practitioner workbook for benefits management in government (requires sign in)

Standards set requirements that people working on government portfolios, programmes and projects need to follow.

A standard can set procedures to be followed, language to be used, and performance criteria to be met in a particular field.

Use a standard when you need to establish clear obligations and requirements that apply across government.

Standards published by Government Project Delivery are subject specific standards which complement the Government Functional Standard for Project Delivery.

When to use a standard

Use a standard when you need to:

• set requirements that need to be followed
• establish consistent obligations across government
• define what compliance looks like

When not to use a standard

Do not use standards for guidance that allows flexibility. Use a guide instead.

Do not use standards for detailed implementation instructions. Use a code of practice instead.

Do not use standards for comprehensive reference material. Use a handbook instead.

Writing a standard

A standard should clearly state what is mandatory using “shall” language for requirements like minimum service levels or data requirements, include advisory elements using “should” language where appropriate, define who the requirements apply to, and specify what compliance looks like.

Standards should support collaboration and interoperability by enabling the development of cross-government platforms, workflow tools and automation, and setting requirements for other publicly available standards to be used (for example BSI or ISO).

Processes, codes of practice and guidance can draw on or support subject specific standards.

Write using clear, unambiguous language. Focus on what is required rather than how to achieve it. Be specific about scope and applicability.

Standards need approval from the Cabinet Office.

Examples

• Government Functional Standard GovS 002: Project delivery
• GPD-PN 02/25: Programme and project data standard

A professional standard sets out the roles and associated skills, experience and learning needed to undertake functional work. This includes any required professional qualifications, whether they are externally accredited qualifications or defined internal or non-regulated requirements.

Use a professional standard when you need to establish clear obligations, competencies and behaviours that individuals need to demonstrate in their professional practice.

When to use a professional standard

Use a professional standard when you need to:

• set requirements for specific roles within the project delivery profession
• define competencies and behaviours expected of project delivery professionals
• establish professional obligations and any ethical requirements
• specify qualifications or experience requirements for roles

When not to use a professional standard

Do not use professional standards for general project delivery requirements. Use a subject specific standard instead.

Do not use professional standards for guidance that allows flexibility. Use a guide instead.

Do not use professional standards for detailed implementation instructions. Use a handbook or code of practice instead.

Writing a professional standard

Professional standards should set out the skills and experience required by functions to undertake current and future functional work in a way that meets the Government Functional Standard for Project Delivery.

Professional standards should support collaboration and interoperability by enabling consistent practice across government and setting requirements for other publicly available professional standards to be used.

Processes, codes of practice and guidance can draw on or support professional standards.

Write using clear, unambiguous language. Focus on what is required of the individual practitioner. Be specific about scope and applicability to roles.

Example

• Project Delivery Capability Framework

Codes of practice provide detailed instructions that need to be followed to meet mandatory requirements.

A code of practice should help deliver defined functional work and be aimed at senior leaders and practitioners.

Use a code of practice when you need to explain how people in particular roles should apply standards and meet their obligations.

The Teal Book is the primary code of practice for project delivery in government.

When to use a code of practice

Use a code of practice when you need to:

• specify what organisations or project delivery teams need to do to meet mandatory requirements from functional standards
• ensure consistent implementation across government
• provide detailed procedures for compliance with standards
• specify what different roles are expected to do

When not to use a code of practice

Do not use codes of practice for guidance that allows flexibility. Use a guide instead.

Do not use codes of practice for comprehensive reference material with specific tools and techniques. Use a handbook instead.

Do not use codes of practice for high-level requirements. Use a standard instead.

Writing a code of practice

A code of practice should reference all necessary processes, subject specific standards, guidance and other supporting documentation, clearly define what different roles are expected to do, explain how to apply mandatory requirements in practice, and never be the sole vehicle for setting mandatory requirements, which should be drawn from a standard.

Write using clear, directive language. Be specific about roles and responsibilities and link clearly to the standards that set the requirements.

Examples

• The Teal Book
• The Green Book
• AI Playbook for the UK Government

Tools and templates provide practical resources that help people complete tasks in project delivery.

Use a tool when you want to provide a practical device, framework or IT application that people can use to achieve specific outcomes.

Use a template when you want to provide a standard format or structure that people can adapt for their own use.

Templates can be standalone resources or form part of larger tools. For example, a business case template might be published separately, or included as part of a comprehensive business case development tool.

When to use a tool or template

Use a tool or template when you need to:

• provide a practical device or IT application for completing tasks
• offer standard formats or structures people can adapt
• give people something tangible to help them do their work
• support continuous improvement and professional
• development through practical resources

When not to use a tool or template

Do not use tools or templates for flexible guidance on general topics. Use a guide instead.

Do not use tools or templates for comprehensive reference material. Use a handbook instead, which can include tools and templates.

Writing a tool or template

A tool or template should clearly explain what it is and what it helps people do, provide instructions on how to use it effectively, include any necessary frameworks or applications, outline when and why to use this particular resource, and link to related techniques, guides or standards where helpful.

Tools and templates should be regularly tested and updated when used across government and signposted from other guidance to aid effectiveness and collaboration. They can be incorporated into handbooks and guides.

Write in clear, practical language aimed at practitioners. Focus on how to use the resource effectively. Include examples of successful application where possible.

Tools and templates are published in the Government Project Delivery product library and can be promoted through news, blogs and events.

Processes describe the sequence of activities and decision points needed to complete a specific workflow or procedure in project delivery. A process can be included in a handbook or referenced separately.

Use a process when you need to map out how work flows between different people, roles or stages.

When to use a process

Use a process when you need to:

• map out a workflow or procedure that involves multiple steps
• show how work moves between different people or roles
• clarify decision points and dependencies in a sequence of activities
• provide a visual representation of how something gets done

When not to use a process

Do not use processes for flexible guidance that can be adapted. Use a guide instead.

Do not use processes for comprehensive reference material. Use a handbook which can include a process.

Do not use processes for mandatory requirements. Use a standard or code of practice which can include a process.

Writing a process

A process should clearly show the sequence of activities and decision points, identify who is responsible for each step, highlight dependencies and handoffs between roles, include timescales or deadlines where relevant, and link to supporting standards, guides or tools to help with a specific step.

You can use visual elements like flowcharts or diagrams where helpful, but they need to be accessible or have text alternatives.

Processes are published in the Government Project Delivery product library and can be promoted through news, blogs and events.

Techniques describe tested ways of doing something in project delivery.

Use a technique when you want to explain a proven method or approach that others working in project delivery can apply to achieve specific outcomes.

When to use a technique

Use a technique when you need to:

• explain a tested method or approach for doing something
• describe a particular way of working that can be applied in different contexts
• provide practical methods for common project delivery challenges
• share proven approaches that others can adopt

When not to use a technique

Do not use techniques for flexible guidance on general topics. Use a guide instead.

Do not use techniques for comprehensive reference material. Use a handbook instead which can include techniques.

Do not use techniques for mandatory requirements. Use a standard or code of practice which can include techniques.

Writing a technique

A technique should clearly explain the method or approach being described, outline when and why to use this particular technique, provide practical steps or considerations for applying it, include examples of how it works in practice, and link to related tools, guides or standards where helpful.

Techniques should be regularly tested and updated when used across government and signposted from other guidance. They can be incorporated into handbooks and guides.

Focus on how to apply the technique rather than general theory. Include real examples where possible.

Techniques are published in the Government Project Delivery product library and can be promoted through news, blogs and events.

Learning provides structured educational content and training opportunities to develop skills and knowledge in project delivery.

Use learning when you want to offer or promote formal courses, workshops or educational events that help people build specific capabilities.

When to use a learning page

Use learning when you need to:

• provide structured training or educational content
• develop specific skills and knowledge in people that work in project delivery
• offer formal learning opportunities like courses or workshops
• support professional development and capability building

When not to use a learning page

Do not use learning for reference material people need to look up. Use a guide or handbook instead.

Do not use learning for quick practical help. Use a tool or technique instead.

Writing learning content

Learning content describes learning opportunities and tells people how to access them. It should explain what the learning covers, who it’s for, what people will learn, and how to book.
Write in clear, engaging language that explains the value and outcomes of the learning. Focus on what people will gain and how it will help them in their work.

Learning content can describe:

• programmes, like structured multi-module offerings like leadership development
• digital or facilitated learning courses
• professional certifications, qualifications or chartered status pathways
• interactive, participative workshops
• resources for structured self-directed learning

The Government Projects Academy decides which learning content to promote on the Government Project Delivery website.

News articles help people working in project delivery understand what’s changing, why it matters, and how it might affect their work.

Use a news article to share a clear, factual update about something new, like a recent announcement or publication.

News articles are published on the Government Project Delivery website homepage and added to the list of news updates. They are also added to the Government Project Delivery news newsletter.

When to use a news article

Use news when you need to announce:

• new or updated standards and guidance
• changes that affect how people work
• significant events or milestones
• new resources or tools

When not to use a news article

Do not use news for guidance that will remain current long-term. Use a handbook or guide instead and then use the news story to promote it.

Do not use news for personal insights or opinions. Use a blog post instead.

Writing a news article

A news article should include context about why this has been worked on, a quote from someone relevant, and links to relevant guidance or background information.

Examples

• Learn AI skills with new project delivery resources (requires sign in)
• Embedding and expanding standardised job titles (requires sign in)

Blog posts share personal insights, lessons learned, and experiences from people working in project delivery.

Use a blog post when you want to offer a personal perspective on project delivery topics, reflect on challenges and successes or share thought leadership.

When to use a blog post

Use a blog post when you want to share:

• personal experiences and lessons learned from project delivery
• reflections on how standards or guidance work in practice
• thought leadership on emerging trends or challenges
• insights from senior leaders or subject matter experts
• a case study with personal insight from someone working on the team

When not to use a blog post

Do not use blog posts for official guidance or mandatory requirements. Use a standard or handbook instead.

Do not use blog posts for formal announcements. Use a news article instead.

Do not use blog posts for factual updates without personal insight. Use a news article instead.

Blog posts can complement a news article and they can refer to each other.

If you want to share a case study, you can publish it as both a blog post (with personal insights) and a separate case study (with neutral language for lessons learned).

Writing a blog post

Blog posts should include the author’s name, role and organisation with a short biography, and provide practical insights readers can apply.

The author needs to be a registered website member with an updated profile and have their profile viewable and searchable.

Events help people working in project delivery learn new skills, share experiences, and connect with others across government.

Use an event listing when you’re running training sessions, workshops, networking events, or presentations that others can attend.

When to use an event listing

Use an event listing when you’re running:

• training sessions or workshops
• presentations or talks
• networking events or communities of practice
• conferences or seminars
• panel discussions or question and answer sessions

When not to use an event listing

Do not use event listings for events that are only open to people from 1 organisation, internal team meetings or one-to-one sessions.

Do not use event listings for events that have already happened. Consider publishing a blog post with key takeaways instead.

Writing an event listing

Before you submit your event, think about what the event is aiming to achieve, who it’s for, and what you want people to know by the end.

An event listing should include a clear synopsis explaining what the event is about, what attendees will see, hear or do, the event objectives and key messages, and a clear agenda with timings.

Speakers need to be registered website members.

Groups provide formal communities and networks for people working in project delivery to connect, share knowledge and collaborate on common interests or challenges.

A group should be open to people outside a single organisation. Group pages are for sharing information about the group, not for managing or administrating it.

Groups include:

• communities of practice, which are groups of practitioners who share knowledge and expertise in a specific area through regular interaction
• special interest groups, which are focused groups that explore particular topics or challenges in depth
• communities of interest, which are broader communities that connect people with shared professional interests or characteristics

When to use a group page

Use a group when you need to:

• create formal communities of practice around specific professional areas
• provide networking opportunities for practitioners with shared interests
• facilitate ongoing knowledge sharing and collaboration
• build professional networks across government organisations
• support specific communities within the project delivery profession

When not to use a group page

Do not use groups for one-off events or activities.

Do not use groups for work that supports delivery of a single organisation’s objectives. This is a work group and not relevant to the wider function or profession.

Writing a group page

A group page should explain what the group does, who can join, how it works, and how to get involved.

Get in touch with the website team (requires sign in) to discuss promoting your group.

Policy papers communicate important policy decisions, updates or positions to chief project delivery officers and heads of the project delivery profession for project delivery in every government department or organisation.

A policy paper is sometimes called a management policy.

Use a policy paper when you need to formally notify people of changes, provide official guidance on policy matters, or communicate strategic direction from the Government Head of Function for Project Delivery or the Government Head of Profession for Project Delivery.

When to use a policy paper

Use a policy paper when you need to:

• formally communicate policy changes or updates
• provide official notification of new requirements or standards
• clarify government positions on project delivery matters
• give direction from senior leadership to all government organisations

When not to use a policy paper

Do not use policy papers for detailed guidance. Use a guide instead.

Do not use policy papers for comprehensive reference material. Use a handbook instead.

Do not use policy papers for setting detailed requirements. Use a standard instead.

A policy paper can reference these separate products, but its main focus should be on the change or notification itself, rather than on guidance for how to comply with it.

Writing a policy paper

A policy paper should clearly state the issue being addressed, specify what action is required and by whom, provide context and background for the policy position, include relevant dates, deadlines or implementation timelines, and be signed by appropriate senior leadership.

Write in a formal, official tone using clear headings like ‘Issue’, ‘Action’ and ‘Context’. Be direct about what is expected and provide sufficient background for readers to understand the implications.

Policy papers need approval from the Government Head of Function for Project Delivery or Government Head of Profession for Project Delivery.

Policy papers are emailed directly to chief project delivery officers and heads of profession in every government department or organisation. They are also published on the Government Project Delivery product library.

Publications provide formal documents that communicate research, analysis or commissioned reports such as evaluations related to project delivery.

Use a publication when you need to share comprehensive findings, research results, evaluation reports or other formal analysis with stakeholders.

Publications are standalone documents that capture information at a specific point in time and are not updated after publication.

When to use a publication

Use a publication when you need to:

• share formal research findings or analysis
• publish evaluation reports or commissioned studies
• communicate research results that stand alone as a document
• provide records of research or analytical work

When not to use a publication

Do not use publications for guidance that people need to follow. Use a guide or handbook instead.

Do not use publications for mandatory requirements. Use a standard instead.

Do not use publications for practical help with tasks. Use a tool or technique instead.

Writing a publication

A publication should have a clear purpose and defined audience, present information in a structured, formal way, include appropriate executive summaries or abstracts, and provide proper citations and references where needed.

Write in a formal, authoritative tone appropriate for the subject matter. Structure content logically with clear headings and ensure it can stand alone as a complete document.

Case studies provide real examples of project delivery in practice, sharing lessons learned and insights from actual portfolios, programmes or projects.

Use a case study when you want to illustrate how approaches work in practice or share valuable experiences with others.

When to use a case study

Use a case study when you need to:

• share real examples of project delivery in practice
• illustrate how particular approaches or techniques work
• communicate lessons learned from actual projects or programmes
• provide practical examples that others can learn from

When not to use a case study

Do not use case studies for guidance that people need to follow. Use a guide or handbook instead.

Writing a case study

Case studies are written as neutral, factual accounts of a portfolio, programme or project. You can also publish a case study as a blog with individual insights, reflections and learning.

A case study should provide clear context, explain the specific challenge or problem being addressed, describe the approach taken and why those decisions were made, outline the outcomes achieved and evidence of success, highlight key lessons learned that others could apply, and be honest about what worked well and what could be improved.

Structure your case study with clear sections like overview, challenge, approach, outcome and lessons. Write in an engaging style that tells the story clearly while focusing on practical insights.

Collections bring together related documents from the Government Project Delivery product library to help users find everything they need to accomplish a specific task or job role.

Use a collection when you want to group relevant guides, standards, tools and other products that the same user would need together.

When to use a collection

Use a collection when you need to:

• group content that the same user would need for their role or task
• help users find all relevant products to accomplish a specific objective
• create curated pathways for users with similar needs
• bring together content from different product types that support the same user journey

When not to use a collection

Do not use collections for comprehensive reference material. Use a handbook instead.

Do not use collections for new content. Collections should only link to existing products.

Do not create collections when users can easily find the same content using filters in the product library.

Collections should only be created when there is a clear user need that cannot be met through existing search and filtering functionality.

Writing a collection

A collection should clearly explain the user need or task it supports, provide helpful context about why these products are grouped together for this user, include brief descriptions of what each linked product offers, organise content in a logical order or by user journey, and link only to products that are current and relevant.

Write clear introductory text that explains who the collection is for and how the different products help them accomplish their task or role.

Landing pages provide entry points and overviews for topics, services or areas on the Government Project Delivery website.

Use a landing page when you need to help users navigate to more specific content relevant to them.

When to use a landing page

Use a landing page when you need to:

• help users navigate to relevant content
• create clear entry points for users

When not to use a landing page

Do not use a landing page for guidance or services. They should only help people get to other products or other content types.

Landing pages are only created for major website sections when there’s a clear user need that can’t be met in other ways.

Writing a landing page

A landing page should give a clear overview of the topic, explain what users can find, link to the most important content, and help users navigate easily.

Don’t provide more than 5 options in a group of links. You should regularly review user journeys to see if the page is meeting its user need.