Government Functional Standard GovS 002: Project delivery (HTML)

This functional standard is part of a suite of management standards that promotes consistent and coherent ways of working across government, and provides a stable basis for assurance, risk management and capability improvement.

The suite of standards, and associated guidance, can be found at GOV.UK government functional standards.

Functional standards cross-refer to each other where needed, so they can be confidently used together.

They contain both mandatory and advisory elements, described in consistent language (see the table below).

The meaning of words is as defined in the Shorter Oxford English Dictionary, except where defined in the Glossary in Annex B.

It is assumed that legal and regulatory requirements are always met.

The purpose of this government functional standard is to set 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.

This standard provides direction and guidance for:

• permanent secretaries, directors general, chief executive officers of arm’s length bodies and sponsoring bodies, ensuring an environment exists which promotes delivery success and integrates with their other activities
• senior responsible owners, ensuring the breadth of practices required for successful delivery are used
• owners of departmental methodologies, developing processes and techniques which are consistent in scope across government
• assurance and audit bodies, for testing best practice
• portfolio, programme and project offices managers, suppliers and their teams introducing the practices

This standard applies to portfolios, programme and projects undertaken within or across government departments and their arm’s length bodies:

• ranging from those listed in the government major project portfolio (GMPP) through to those at local business level
• whether for digital, infrastructure, transformation, service delivery, military capability, property, regulatory compliance or other purposes
• regardless of delivery methodology or techniques used

Other public sector organisations, devolved or local, might find this standard useful.

Note: an organisation, in the context of government functional standards, is the generic term used to describe a government department, arm’s length body, or any other entity that is identified as being within scope of a functional standards.

The structure of the standard is shown in Figure 1.

The following standards are directly necessary for the use of this standard:

• GovS 003, Human resources
• GovS 005, Digital
• GovS 006, Finance
• GovS 007, Security
• GovS 008, Commercial
• GovS 009, Internal Audit
• GovS 010, Analysis
• GovS 011, Communication

A functional standard supports achievement of the outcomes sought by an organisation. It sets expectations for what needs to be done and why relating to the functional work within its scope, in order to achieve those organisational outcomes.

Note: for expectations relating to management of a function across government, and management of functional standards, see GovS 001, Government functions.

Those engaged in project delivery shall ensure:

1. delivery objectives are aligned to government policy and organisational objectives
2. outcomes and enabling outputs meet the identified need and are validated by stakeholders
3. there is continuing business justification to confirm benefits can be realised and risks managed within the organisation’s risk appetite, and that unjustified work is terminated
4. accountabilities and responsibilities are defined, mutually consistent and traceable across all levels of management
5. governance and management frameworks and the control environment are proportionate and appropriate to the nature and complexity of the work and the level of risk
6. work is appropriately defined, planned, monitored and controlled, quality is actively managed to maximise the likelihood of success, and defined working methodologies are tailored for use accordingly
7. work is undertaken in multidisciplinary teams and is assigned to people who have the required capability and capacity
8. the transition of capabilities to operations is planned, and portfolio, programme or project closure managed, with ongoing operational responsibilities agreed and accepted
9. experience and lessons are captured, shared and used to promote future performance improvement
10. public service codes of conduct and ethics and those of associated professions are upheld

This section provides essential background information for the use of this functional standard.

Note: see The Teal Book [16] for further guidance on the context of project delivery in government.

Portfolio, programme and project management is an integrated way of meeting the government’s ambitions, driving better decisions and increasing the likelihood of successful outcomes. Collectively, portfolio, programme and project management are referred to in government as project delivery.

Public policy represents the government’s role in improving the welfare, security and prosperity of the nation and is concerned with:

• developing and improving government strategies
• ensuring democratic accountability
• overseeing delivery

Policy interventions can take many forms and those which are extensive and complex to implement can be managed using project delivery, involving policy makers and project delivery professionals working together as a team (see 6.4.2).

Evaluation is the systematic assessment of the design, implementation and outcomes of a policy intervention. Evaluation is built into the portfolio, programme and project plans in order to collect evidence and understand the impact and value for money of a policy intervention.

Note: further information and guidance on evaluation can be found in the Magenta Book (requires sign in) [17].

A portfolio comprises part or all of an organisation’s investment required to achieve its objectives. Governed through its portfolio (or business) plan, a portfolio comprises work components, such as other portfolios, programmes, projects and other related work.

A programme is a unique, temporary, flexible organisation created to co-ordinate, direct and oversee the implementation of a set of projects and other related work to deliver outcomes and benefits related to a set of strategic objectives. Programmes can be undertaken in one or more tranches (phases), each of which is structured around distinct step changes in the solution delivered and the resultant benefit realised.

A project is a unique, temporary management environment, undertaken in stages, created for the purpose of delivering one or more business products or outcomes. A project might be standalone within a portfolio or part of a programme. Other related work, not managed as a programme or a project, might include:

• support services (see 4.4.11), solution architecture, finance and human resources
• ongoing improvement initiatives not run as projects, but using a defined approach, such as agile delivered platform-based upgrades (see Annex D), six sigma and LEAN service delivery, business as usual operations

Note: for example, stages can represent agile releases and work packages can represent sprints.

A work package is a set of information relevant to the creation of one or more deliverables or outputs. It comprises a description of the outputs required, work plan and details of any constraints.

Figure 2 shows the hierarchical relationship between work components, with each higher-level component comprising the sum of all connected lower-level components.

Work components may cross organisational and departmental boundaries.

Note: the use of the terms ‘project’ and ‘programme’ is not always indicative of the formal definitions in this standard; however, the distinction is important when designing a programme or project governance and management framework.

This project delivery standard defines a number of practices needed for successful outcomes. It defines the why and the what for each but does not define how work is to be undertaken. For example, ‘agile’ approaches are needed in many cases but could be used at any point in the project delivery hierarchy (see Figure 3 Example showing where agile approaches can be used).

Note: delivery approaches may be predictive, incremental, iterative, adaptive or hybrid, including ‘agile’ approaches.

Nor, in the case of a project, does the standard define what the project life cycle stages should be, only that they can be mapped to the reference life cycle. The project might only include the delivery of outputs when the project is part of a programme, or could include an extended period of operation in other situations. The delivery approaches and stages need to be defined to suit the outputs and outcomes delivered and the delivery approaches taken. In a project where the work is predominantly agile, the project stages of discovery, alpha, beta, live and retirement meet that requirement (see GovS 005, Digital). Annex D includes some examples.

Decisions relating to project delivery should be made, and approvals and authorisation given, in a timely manner, in accordance with the organisation’s governance and management framework. Government policy should be complied with. Decisions should be made by assessing options against defined criteria and in consultation with stakeholders and subject matter experts. Options shall be assessed in accordance with GovS 010, Analysis.

Decisions should relate to, but not be limited to:

• approving vision and strategy
• approving portfolio plans
• approving business cases
• approving plans and baselines
• setting risk appetite and tolerance
• initiating a programme, project or other related work
• authorising the start of a new project stage, for example, at a gate or decision point (see 6.3) or for a new tranche of a programme
• selecting suppliers
• deciding options for further study
• selecting a solution
• pausing, terminating or closing work

Decisions should be:

• holistic, taking account of the external context, whole life of outputs (such as in life service, disposal) and negative impacts
• communicated to the relevant stakeholders

Decisions may be:

• conditional, with responsibility for fulfilling such conditions defined
• phased to take into account risk (see 6.3)

A programme, project or other related work shall be governed through a business case or equivalent document, in accordance with HM Treasury requirements. If a project or other related work is part of a programme, its business case may be included within the programme’s business case. A business case should include a cost-benefit analysis and demonstrate strategic, economic, commercial, financial and management justification. The business case shall be prepared and the investment appraised in accordance with GovS 006, Finance.

The business case should be developed over a number of phases and should be updated to reflect changes and reviewed prior to every gate or decision point to justify continuing the work.

The accounting officer shall approve government major projects prior to submission to HM Treasury for authorisation [12]. Accounting officer approval shall be supported by an Accounting Officer Assessment for the outline business case and, when advised by the senior responsible owner, for any subsequent, materially changed business cases [14].

Note: guidance on investment appraisal, business cases and evaluation is provided in the Green Book (requires sign in) [5].

Cabinet Office expenditure controls require central government bodies to obtain expenditure approval from Cabinet Office ministers, based on professional advice from relevant functions, before certain expenditure is made or committed. Organisations should take advice from relevant functional experts in advance of planned expenditure, and comply with expenditure controls guidance.

Note: expenditure control guidance can be found in Managing Public Money [1] and in the annual consolidate budgeting guidance; see GovS 006, Finance.

Portfolio management is a coordinated collection of practices and decisions that together enable an effective balance of organisational change and business as usual, whilst remaining within a specified funding envelope and constraints.

Portfolio management shall be an integral part of an organisation’s business planning and control activities.

The portfolio director (see 4.4.5) and manager (see 4.4.6) should:

• ensure investment is aligned to the government’s policy and departmental vision and strategy
• maximise benefits realised by the portfolio as a whole
• balance the portfolio to cover short-term and long-term objectives
• ensure risks across the portfolio are within the organisation’s risk appetite
• optimise the organisation’s capability and capacity to ensure the portfolio can be delivered
• ensure those impacted by the portfolio’s outcomes can take on the changes
• optimise the use of funds and resources, bearing in mind the associated risks

Each portfolio shall be under the direction of a named portfolio director (see 4.4.5) and be managed by a named portfolio manager (see 4.4.6), as appropriate, supported by a team.

A portfolio governance and management framework (see 4.1), defining how a portfolio is to be directed and managed, shall be established, maintained, and communicated to appropriate stakeholders. The portfolio’s governance and management framework should include, but not be limited to:

• roles and accountabilities, processes, methods, techniques, guidance, templates and tools for governance (see 4) the management practices (see 5.3) and supporting practices (see 7 and 8)
• the planning horizons to be used and how often the plan should be reviewed and updated
• the types of work component to be included in the portfolio, together with criteria to identify them
• criteria and techniques for categorizing, prioritising and selecting the portfolio’s work components
• processes for the initiation and management of work components
• how resources and funds are allocated
• a reporting framework

The portfolio’s governance and management framework should align to and work with:

• the organisation’s governance and management framework and decision-making authorities
• other organisational processes and practices, such as those for strategy and policy development, business planning, finance, performance reporting, capability and capacity management, enterprise risk management, and communications

A record of the portfolio’s work components should be kept up to date, including, for each work component: component type; person responsible; status (for example: proposed, in progress, paused, terminated, completed); interdependencies between components under different senior responsible owners (see 4.4.8); an indicator denoting whether the component is required to be reported as part of the Government Major Projects Portfolio. Additional data may be included for management, analysis and reporting purposes.

Portfolio management responsibilities may be assigned as each organisation sees fit and should be integrated with those responsible for the organisation’s business planning activities. An organisation’s overall portfolio may be managed as a set of sub-portfolios.

The organisation’s group undertaking portfolio management may provide other services, such as those provided by a portfolio support office (see 4.4.10), including methods, advice, resourcing, or tools support.

Note: the portfolio’s governance and management framework can be tailored from The Teal Book [16]. Further guidance can also be found in ISO 21504 [33].

Programme and project management are structured frameworks for defining and undertaking change. They provide a framework for implementing policy and business strategies to enable the government and organisations to achieve outcomes and benefits of strategic importance. Programme and project management includes the planning, delegating, monitoring and control of all aspects of a programme or project and the motivation of those involved to achieve the defined objectives within the defined constraints, such as cost, benefit, schedule, quality, scope, and risk.

Each programme and project shall be under the direction of a named senior responsible owner (see 4.4.8) and be managed by a named programme or project manager (see 4.4.9), as appropriate, supported by a team.

A programme and project governance and management framework (see 4.1), defining how a programme or project is to be directed and managed, shall be defined and established. The governance and management framework may change to reflect the phase of the work being undertaken. The governance and management framework should include:

• authority and decision-making roles and rules, including, but not limited to, governance tiers, initiation of new work, prioritisation, assignment of resources and funds, and issue resolution
• roles and accountabilities, processes, methods, techniques, guidance, templates and tools to be used to undertake the practices in this standard

The governance and management framework of jointly sponsored work should be defined to reflect the legitimate interests of the participating organisations.

The programme’s or project’s governance and management framework should align to and work with:

• the organisation’s project delivery governance and management framework (see 4.1.3)
• the portfolio’s governance and management framework (see 5.2)
• other organisational processes and practices, such as those for finance, human resource management, performance reporting, capability and capacity management, risk management, and communications

Note: the governance and management framework can be tailored drawing on departmental methodologies or, for major projects, can be specially developed; guidance can also be found in The Teal Book [16].

The life cycle provides a phased approach for governing work and underpins the plan, from start to finish. The life cycle shall be defined and should include approval gates/decision points and assurance reviews. For government major projects the life cycle and its attributes shall be defined in accordance with this standard.

A project shall comprise stages, each of which shall be preceded by a gate (decision point) to authorise the start of the next stage and commit resources and funding.

The project life cycle should be defined to suit the circumstances by tailoring and mapping to the reference life cycle shown in Figure 5 and Annex C. The number of gates and stages, types of assurance review and form of the business case should be chosen to ensure governance is appropriate and proportionate to the circumstances, with simpler projects having fewer stages (minimum of two) and more risky projects having more stages. See Figure 5 and Annex C.

A programme may be phased in one or more tranches and might cover the whole life of a product, service or system (see Figure 6).

The following shall be defined for each gate or decision point:

• criteria for providing authorisation
• the decision makers
• who should be consulted
• the type of assurance review required prior to the decision (see 4.2)

Criteria should include, but not be limited to the following:

• work aligns with policy and strategy and is still needed
• the business case is acceptable
• risks have been identified and are acceptable or can be mitigated
• the solution is (or is likely to be) acceptable
• there are funds and resources to complete the work and support any outcomes
• there is a plan for the next stage and outline plan for the remainder of the work

A decision might result in approval to proceed, a request for work to be revised, or deferral or termination of the project.

Model project life cycles may be developed for undertaking particular types of project or programme.

Note: Annex C includes a detailed example project life cycle. Annex D includes agile delivery and extended life cycle example.

Note: phases for a project are called stages. Stages can reflect the approach taken, for example, developed using an agile approach, such as discovery, alpha, beta (private); beta (public) or in ‘waterfall’, such as analysis, design, development, testing, implementation. Further detail and examples of a project life cycle are included in Annexes C and D.

Note: see Figure 5 for detail for each project in a programme.

Note: see The Teal Book [16] for guidance on programme and project life cycles.

Planning and control support practices ensure work is planned, and corrective and preventative actions taken, to ensure delivery follows the baselined plan.

The planning and control practices should be managed and monitored, throughout the life cycle (see 6.3), using a defined and established approach that is improved through use (see 8.10). Work shall be defined, planned, monitored and controlled.

Note: guidance on how to control work can be found in The Teal Book [16].

Managers of work components should be set permissible tolerances within which no escalation is required to the next level of management. Tolerance levels can cover, but not be limited to costs, benefits, schedule, quality, scope, performance, and risk.

The planning and control practices are the responsibility of the relevant manager, for example, portfolio manager for a portfolio, project manager for a project or team manager for a work package. Such practices may be delegated to a support office manager (see 4.4 for role definitions).

Note: guidance can be found in The Teal Book [16]. In addition, the APM and PMI bodies of knowledge [36-40] and British and international standards [29-35] can be referred to.

Benefits management ensures that the measurable value and other positive impacts resulting from the work are identified, planned and managed so that they can be realised in practice. The relevant stakeholders’ expectations regarding the benefits to be realised should be understood by the team developing the solution. Benefits should be identified, analysed, defined, planned and tracked and included in the overall plan for the work (see 7.2). Forecasts of benefits should take into account negative impacts resulting in disbenefits. Benefits should be assessed for a number of options before a solution is chosen (see 8.4) and included in a business case (see 4.3), in which potentially conflicting pressures, such as costs, benefits, schedule, quality, scope, performance, and risk are balanced. Options shall be assessed in accordance with GovS 010, Analysis.

Each discrete benefit should be assigned to an owner who has responsibility for forecasting and monitoring it. Benefits should be reassessed throughout the duration of the work as new benefits might emerge as the work progresses and expectations might change.

Benefits trigger points should be included in schedule plans (see 7.2). Once triggered, actual benefits realisation should be tracked against the plan.

There should be two-way traceability between benefits, outcome, solution, outputs, requirements and objectives (see Figure 8 and 7.8).

Note: benefits mapping might be used to demonstrate traceability.

Resource, capacity and capability management balances the supply and demand for appropriate resources (such as skilled people, equipment, material and facilities) to be deployed when needed. Resources can be sourced from within government, by recruitment or from the supply chain (see 7.11).

A comprehensive view of future resource needs should be developed and maintained, with possible shortfalls identified and addressed. Resources should be acquired or developed to meet the planned needs. If insufficient resources are available, work should be re-planned to reflect such constraints. Business, operational and service continuity measures should be in place in the event of the loss of critical resources.

Resource plans should:

• take into account the development, retention and planned reassignment of people to ensure their skills are retained within government organisations
• be consistent with the organisation’s workforce plan

Note: ‘appropriate resources’ means, for materials, equipment and facilities, the required quantity with the right specification. For people it means the right skills, competences and expertise to undertake the work. See [11].

Note: see GovS 003, Human resources on workforce planning.

Reporting ensures the management team(s) and interested parties are aware of the current status of the work and outlook relative to the baselined plan (see 7.2.5), particularly with respect to the likelihood of achieving the objectives.

A reporting framework should be defined and established to meet the needs of the identified report recipients in a timely manner. A report should be factual and realistic, highlighting progress to date, whether the current work scope is likely to be completed to plan, prevailing risks and issues and the decisions or direction required. Appropriate milestones and performance indicators should be included in the report to reflect progress and the achievement of outputs and outcomes and, where appropriate, benefits realisation. Performance indicators should reflect the delivery method used and degree of confidence in the forecasts (see 7.2.2).

Each report should state the period or date the report is related to and the date on which the report was published, or if live, created. The form of a report should be appropriate and proportionate to the work being reported on and the roles being reported to.

Note: examples of report types include Gantt, slippage, backlog, visibility and burndown charts.

Government major projects shall be reported annually, with quarterly updates in a format defined by the National Infrastructure and Service Transformation Authority and in accordance with the Government’s transparency policy.

Note: reporting applies to information flowing within and between portfolio, programme, project and work package teams. Information flow with wider stakeholders is dealt with in 7.13

Risk and issue management ensures objectives are more likely to be achieved, bearing in mind complexity, uncertainty, unexpected events and threats and opportunities from undertaking the work, using the solution, and from the external environment.

Risks and issues should be:

• identified, assigned an owner and assessed, taking into account the impact, likelihood and proximity of the triggering causes
• responded to through exploitation (for opportunities) or mitigating actions (for threats) to eliminate, reduce or avoid consequences or reduce the possibility of occurrence; risks may be accepted
• monitored to resolution and closed when no longer valid

Residual and secondary risks, if any, should be identified and responded to.

Risk controls should be reviewed to ensure they are still effective.

Risks should be managed as individual risks and collectively. Contingency should be retained at an appropriate level in the project delivery hierarchy (see Figure 2) and authorised if needed through change control (see 7.7).

Overall risk shall not exceed the organisation’s risk appetite and tolerance without authorisation.

Risks might be related to:

• the chance of an event occurring and its potential consequences
• an unknown variable for which assumptions need to be made (for example number of users, inflation) which should be understood, articulated in the business case and, where possible, quantified using cost-benefit analysis

The circumstances under which work will no longer be viable or the solution relevant, should be determined, using techniques such as simulation, contingent scenarios and sensitivity analysis.

Risks and issues which an owner cannot resolve should be escalated or reassigned as necessary. The project delivery hierarchy (see Figure 2) can be used as a basis for escalating or reassigning risks. Risk owners may be outside the formal hierarchy but should be responsible to a person in the project delivery management structure.

Note: guidance on risk management can be found in the Orange Book (requires sign in) [6] and management of risk in government [7].

Change control ensures only beneficial or necessary changes to a baseline are implemented. Changes might originate from any stakeholder, including policy makers, executive management, end users, suppliers or team members. Alternatively, a change might result from a risk or issue which cannot be resolved. Criteria should be defined to:

• define what aspects of the work should be change controlled
• direct which individuals or groups have the authority to authorise changes (see 4.3)

Change requests should be recorded, identified and defined. The impact of a change should be assessed in terms of impact on the business case, objectives, outcomes, solution and plan. Changes to interrelated deliverables (products or elements of a solution) should be controlled as a group and traceability between elements maintained (see 7.8). Change requests should be accepted, rejected or further direction given (see 4.3).

An implementation plan should be developed, prior to receiving authorisation to implement a change. The decision should be communicated to interested parties. Once a change has been incorporated into the baseline and affected information updated, the change request should be closed.

Traceability management ensures the relationships among the different elements of a solution and the associated management documentation is known, such that, at any point in time:

• change control can be applied effectively (see 7.7)
• the makeup of a solution and parts is defined and reproducible (see 8.4)

The elements to be managed should include those produced by suppliers and internally, tools used during the design, development or manufacturing of a solution, and the management deliverables. Information with respect to traceability should be managed in accordance with clause 7.9.

Each element should be identified in terms of status and version. There should be two-way traceability from the higher-level to the lower level elements that comprise it as well as among different elements.

Traceability management should include:

• planning the scope of and managing the relationships between elements, including baseline control
• identifying and understanding the relationships between elements at a given point in time
• reporting to ensure those requiring this information are informed
• verifying the accuracy of the records

Note: different sectors can have different names for this practice, such as configuration management, parts management and asset management.

Information and data management ensures information and its underlying data (physical or electronic) is available and reliable for undertaking work and making decisions.

The information and data which needs to be managed should be identified. This should include data and information relating to the solution and its development, plans, progress assessments, reviews and audits, contracts, reports and communications. Information should be recorded on receipt, validated as correct, securely stored, distributed to, and retrievable by those who need it.

Note: information and data concerning a solution can be related to requirements, drawings, designs, specifications, building information modelling and digital twins (see section 8).

The framework for managing data, information and its quality should be defined. Business, operational and service continuity measures should be in place in the event of a disruptive incident (see 7.6).

New sets of information, such as documents, should be reviewed, approved, version controlled and, when no longer required, withdrawn and archived. The status, security classification and provenance of information and data should be clear.

Where relevant, information and data should be handed over for on-going operational management. When not handed over, information should be retained to meet statutory, contractual and wider business requirements. The integrity of groups of related information should be maintained (see 7.8).

GovS 005, Digital shall be complied with, with respect to data handling.

GovS 007, Security shall be complied with, with respect to data and information security.

Note: information management can include web content management, document management, records management, digital asset management, learning management, building information modelling and content systems.

Financial management ensures the efficient and effective management of money (funds) to accomplish the objectives of the organisation.

The level of funding needed should:

• be determined, in the short and long term for the portfolio, programme or project including subsequent in-life or running costs.
• be consistent with the respective plans (see 7.2)
• represent value for money [15]

Sources of funding should be identified and secured. The financial governance and management framework should be defined, including financial accountabilities, levels of delegation, approvals and monitoring.

Note: funding sources can include those from grants, estimates, tax, public dividend capital, public borrowing, external borrowing and income generation. See Managing Public Money [1].

Financial reports should be reliable and provided to decision makers and to managers of work components in a timely manner.

GovS 006, Finance shall be complied with.

Procurement ensures products or services bought as part of resourcing the work or developing the outputs are of the appropriate quality, represent value for money and can be delivered within an acceptable level of risk.

Those leading procurement and contract management activities should have a comprehensive knowledge and experience of the context, goods or services required and be able to interpret business needs and translate them into contractual requirements.

Note: this expertise is often referred to as ‘intelligent client’.

Appropriate contract strategy and procurement packages should be determined, suppliers selected against defined criteria and the contracts formally agreed. There should be two-way traceability between the contract and the appropriate part of the plan (see 7.8). Contracts should be designed to reflect the type and method of delivery and reliability of the supply chain. The scope of contracts should include the documentation and tools required for the operation of the service or product.

Once a contract is agreed, the contractual obligations, including management of dependencies, should be complied with, including timely payments to suppliers. Supplier performance and quality should be monitored and deliverables and services only accepted after verification against the contractual requirements.

GovS 008, Commercial relating to contract management shall be complied with.

Stakeholder engagement ensures the needs and concerns of stakeholders are addressed sufficiently to enable the objectives to be met.

Stakeholders should be identified, and their interests and expectations understood and represented. A plan should be developed defining how to engage them in a co‑ordinated and appropriate way. The engagement plan should be implemented, monitored and updated to reflect newly emerging stakeholders and changes in the position of existing stakeholders. Stakeholder attitudes should be assessed, updated and validated throughout the work.

Note: depending on the stakeholders, engagement can be done in a number of ways, including face to face contact, meetings, or through collaborative working approaches, such as agile or through communications (see 7.13).

Communications ensure interactions with the stakeholders are effective and likely to contribute to the successful delivery of the work.

Communications should be designed and co-ordinated to ensure the right messages are addressed to the right audience, at the right time and in a way which is acceptable and accessible to the recipients. Communications should be planned to match the stakeholders’ needs and include feedback mechanisms and effectiveness measures. The impact of communications should be assessed and, where appropriate, responded to. The communication plan should be adjusted if needed, to achieve successful change.

GovS 011, Communication shall be complied with.

Note: depending on the stakeholders, engagement might be through press releases, news channels, adverts, posters, social media, web sites and leaflets.

Solution delivery ensures that an appropriate and sustainable solution is developed and enables the achievement of the required objectives.

Solution delivery is the responsibility of the programme or project manager (see 4.4.9), supported by subject matter experts for the respective practices. The solution delivery practices should be managed and monitored, throughout the life cycle (see 6.3), using a defined and established approach that is improved through use (see 8.9).

Note: see The Teal Book [16] for guidance on solution delivery practices.

Note: for more information see BS ISO-IEC-IEEE 15288 [35].

Quality management ensures outputs are fit for purpose to achieve the objectives.

Quality shall be actively managed to maximise the likelihood of success by determining the degree to which the features and inherent or assigned characteristics of an output or solution (whether product, person, process, service and/or system) meet expectations or stated needs, requirements and specification (see 8.6).

A quality management framework should be defined and established, which is appropriate to the outputs and work required. People should be trained, briefed and competent to undertake the work assigned to them.

The quality management framework should include:

• quality assurance to provide confidence that outputs are likely to match the defined quality criteria
• quality control to monitor and verify compliance with the specified designs and to identify ways to eliminate causes of unsatisfactory performance

Note: the quality of the solution is dependent on the choice of appropriate design and development methodologies. Different approaches are appropriate in different circumstances, for example an iterative, agile delivery approach for digital service (see GovS 005, Digital).

Managing requirements ensures the needs of stakeholders are understood and considered throughout the design and development of the solution.

Requirements should be refined, elaborated (for example, as agile epics and user stories) and evolve with the design and development of the solution until a viable solution is defined and approved. Multiple iterations might be needed to fully understand the requirements.

A common understanding of the outcomes for all phases of the solution’s life cycle (including during development, in-life and disposal) should be agreed between those requesting the work and those undertaking the work. Requirements must take into account relevant statutory, regulatory and other constraints such as inclusion, health and safety (see 8.12), environment and sustainability (see 8.13). The requirements should be determined for those affected by the development and use of the outputs and subsequent outcomes, such as the public, end users, operational and maintenance staff, developers, constructors and manufacturers. Requirements should be uniquely identifiable, current, mutually consistent, understandable, unambiguous, prioritised and validated. There should be two-way traceability between the requirements and the elements of the design (see 7.8). Changes to requirements should be aligned to the objectives of the work component, and should be controlled (see 7.7).

Solution design ensures the outputs meet the requirements and are likely to achieve the desired outcomes, realise the required benefits and represent value for money. Design should be in accordance with a defined approach and may be predictive, incremental, iterative, adaptive or hybrid, including agile approaches.

Solution design may evolve as requirements are elaborated and as design and development progress. The solution design (or target operating model) should include the outputs needed to achieve the desired outcomes, including, but not be limited to, people, software, equipment, operations and maintenance products, manufacturing, security, information, organisation design, supply chain, performance characteristics and desired behaviours. The solution should be defined sufficiently to enable its parts to be verified as correct. There should be two-way traceability between the design elements and the plan (see 7.8).

The team undertaking the design should consider a range of solution options (design approaches, design concepts, or preliminary designs) that potentially satisfy the requirements and take into account complexity and value for money [16]. After analysis a preferred solution should be recommended for implementation. Options shall be assessed in accordance with GovS 010, Analysis.

The entire solution should be considered with progressive breakdown into its constituent elements, including those undertaken and implemented by suppliers. Interactions between elements and the operating environment should be known and considered.

Note: the breakdown of the solution is also called product breakdown, system element hierarchy and system decomposition [35].

Note: taking account of the entire solution is often referred to as system-wide or whole system thinking.

Solution development and integration ensures that the designed solution is built in a defined way such that the elements comprising the solution work together within the proposed development and operating environments.

A strategy should be developed defining the approach to be taken for sequencing, delivery and integration of the elements of the solution, including any special temporary environments or facilities required.

Working methods and processes should be defined together with how different elements of the designed solution relate (see 7.8) and are integrated such that the solution works as a whole.

Verification checks the correctness of a solution (or part of a solution) to confirm that it complies with the specified design. It should be aimed at detecting faults or failures.

Validation ensures the right problem is being addressed and the solution is likely to fulfil the requirements when operating in its intended environment. Validation should be applied to the solution or a significant part of it and should be aimed at demonstrating stakeholder satisfaction.

Verification and validation should be continuous throughout the life cycle and may be iterative in nature with the requirements, design and solution evolving as work progresses. The methods used for specialist work should include appropriate approaches and planned activities for both verification and validation.

Note: methodologies for verification and validation can include, but are not limited to: prototyping, simulation, inspection, show and tell, analysis, demonstration, test, trials or pilots, and sampling.

The purpose of managing change is to prepare, equip and support organisations and individuals (for example, users, citizens) to change their approach and, where appropriate, behaviours and to embed the required changes.

Organisational and societal change aspects shall be addressed and planned into the solution design and delivery strategy from the start of the programme or project and throughout the life cycle (see 8.4).

Each programme and stand-alone project should have a vision and target operating model for the future state. The current state of the target groups should be assessed, and appropriate techniques should be used to design and manage the required business or societal changes. The readiness of the target groups to accept the changes should be continually assessed, and progress towards achieving the future state should be tracked. Milestones representing the achievement of outcomes should be included in the plan (see 7.2). Once a transformed operating approach has been implemented, it should be monitored to ensure behaviours and practices are sustainable and do not revert.

The purpose of transition is to establish the capability for a solution to work within its intended environment.

A strategy and plan for transitioning all or part of the solution to the interim and final operational environments should be developed, taking into account, where applicable:

• related organisational and societal change activities (see 8.7)
• related verification and validation activities (see 8.6), including formal acceptance
• contractual obligation (see 7.11)
• sequencing to minimise unexpected side effects
• the need for business, operational and service continuity
• transfer of ownership
• decommissioning of legacy capabilities which are to be disposed of

Note: the strategy for transition is usually developed as part of the design of the solution (see 8.4).

Note: transfer of ownership can be incremental or in full.

Transition should be tracked against the plan, and defects recorded and resolved. Records of traceability should be maintained (see 7.8), to ensure the configuration of the solution at each transfer of ownership is known.

The purpose of use and disposal is to:

• use, maintain and operate the solution to fulfil its defined purpose
• shut down all or part of a solution and dispose of residual resources, data, facilities and materials, if no longer required

The programme or project manager and team should oversee and support the initial period of use to address outstanding actions, risks and issues and to oversee any contractual warranty periods (see 6.3 and Annex C, reference life cycle).

Note: the names of a warranty period can vary by contract and are typically also called a maintenance period and guarantee period.

The use of the solution should be monitored using pre-defined performance indicators. Preventative and corrective action should be taken as necessary. Risks and issues should be identified and addressed (see 7.6). Changes for maintenance and upgrades to the solution, whether evolutionary through pre-defined processes or incremental through project-based working, should be managed in accordance with this standard. Traceability of the as-built baseline should be maintained throughout the period of use (see 7.8).

Note: typical performance indicators in use include user feedback, operational metrics and financial measures. Non-functional performance, such as accuracy, security, availability, usability and timeliness.

Those accountable for the disposal of a solution and its parts should plan disposal to be sustainable (see 8.13), taking into account factors such as costs, disposal sites, environmental impact, health and safety issues, security, handling, shipping as well as relevant regulatory requirements.

Note: disposal options include dismantling, reusing for another purpose, recycling, reprocessing and destroying and include the withdrawal or redundant documentation.

Note: the approach to disposal is usually developed as part of the design of the solution (see 8.4).

Disposal of the solution should be planned and controlled so that impacted stakeholders are aware of what is happening and how it could affect them (see 8.7). Information and data relating to disposal capabilities should be updated and archived in accordance with organisational policies (see 7.9).

Learning from experience helps avoids repeating the same mistakes and helps spread improved practices to benefit current and future work.

At the start of the work, those involved and key stakeholders should identify and apply relevant lessons from previous experience when planning the work. Throughout the life cycle, lessons should be continually captured, evaluated and action should be taken to mitigate delivery risk and facilitate continual improvement of the final outputs and services. Organisation leaders, (including arm’s length bodies) and owners of standards, processes, methods, guidance, tools and training, should update their knowledge sources and share learning as appropriate.

Induction and training ensure team members are working effectively as soon as practical through being briefed on the context of their work and the required operational procedures.

For programmes and projects, induction should include, but not be limited to, ensuring a briefing on the specific role being undertaken (see 4.4), processes to be followed and specialist training required, as well as providing the necessary facilities and granting appropriate security access.

Organisationally, training should include, but not be limited to, defining a training strategy for project delivery, analysing training needs, defining, developing, and maintaining briefings/ courses, planning, delivering and monitoring training and development events.

Induction and training activities shall comply with GovS 003, Human resources.

The purpose of managing health and safety is to ensure the public and those engaged in project delivery, over the whole life of the solution, are not at risk. Health and safety risks should be assessed in order to ensure accidents and threats to health are reduced to an acceptable level. Legislation shall be identified and must be complied with. In particular managers shall ensure:

• safety management information is provided
• staff are aware of and trained to use safety related equipment
• hazards are identified and preventative actions taken
• risk assessments are conducted and findings acted on
• accidents are reported, recorded, and actions taken to reduce the risk of recurrence

Note: Attention is drawn to the Health and Safety at work Act 1974, the Management of Health and Safety at work regulations 1999 and equivalent in other jurisdictions.

Sustainability is concerned with meeting the present needs without compromising the environment for future generations. Sustainability requirements should be included in the objectives and scope for the work and documented (see 8.3). Legislation shall be identified and must be complied with. If not already covered in organisation‑wide policies and procedures, the management of environment and sustainability should be covered in or referenced from the respective portfolio, programme’s or project’s governance and management framework.

When establishing the sustainability of a solution’s outputs and outcomes the assessment should cover the whole life cycle of the solution, including decommissioning or disposal.

All references are correct at the time of publication, users should check for updated versions.

Note 1: publications listed as being produced by the Infrastructure and Projects Authority are now owned by the National Infrastructure and Service Transformation Authority.

Note 2: British and international standards contain supplementary information and are available by subscription, purchase and from UK local libraries’ on-line reference services. These publications may offer useful context and guidance; however, users should ensure that any referenced material is interpreted and applied in a way that remains consistent with the requirements of this standard.

Note 3: The Association for Project Management (APM) is the UK’s chartered professional organisation. The Project Management Institute (PMI) is based in the USA and has chapters in the UK. Their references are free online to members or by individual purchase. The Software Engineering Institute is a federally funded research and development centre sponsored by the US Department of Defense. These publications may offer useful context and guidance; however, users should ensure that any referenced material is interpreted and applied in a way that remains consistent with the requirements of this standard.

See also the common glossary of definitions which includes a list of defined terms and phrases used across the suite of government functional standards. The glossary includes the term, definition, and which function owns the term and definition.

A

accountable (person)

Someone who is accountable is required and expected to justify actions or decisions to a person or body with greater authority, from whom the accountability has been formally assigned.

Note: accountabilities can be tiered such that there is a hierarchy of accountabilities, with a higher-level having overall accountability over lower- level accountabilities.

Note: an accountable person usually has associated formally delegated authority for their actions and decisions, such as through delegation letters.

assurance

A general term for the confidence that can be derived from objective information over the successful conduct of activities, the efficient and effective design and operation of internal control, compliance with internal and external requirements, and the production of insightful and credible information to support decision making. Confidence diminishes when there are uncertainties around the integrity of information or of underlying processes.

B

baseline

A measurement, calculation, or location used as a basis for comparison. In a project delivery context baselines typically apply to plans and to sets of data relating to the solution.

Note: examples include schedule baseline, cost baseline, requirements baseline, design baseline.

benefit (project delivery)

In the context of project delivery, benefit is the measurable value or other positive impact resulting from an outcome perceived as an advantage by one or more stakeholders, and which contributes towards one or more objective(s).

business case

The justification for an organisational activity (strategic, programme, project or operational) which typically contains benefits, outcomes, timescales, costs and risks against which continuing viability is tested.

C

constraint (project delivery)

In the context of project delivery, a constraint is a limitation or restriction on planning or undertaking work.

Note: planning constraints can include, but are not limited to scope, performance, time, cost, resources and risk.

D

delivery strategy (project delivery)

In the context of project delivery, the delivery strategy outlines longer term objectives, outcomes and outputs, and the means to achieve them, to inform future decisions and planning and includes phasing and strategies for commercial, business, societal change and solution delivery aspects.

disbenefit (project delivery)

In the context of project delivery, disbenefit is the measurable value or other impact resulting from an outcome perceived as a disadvantage by one or more stakeholders, and which partially or fully negates the achievement of one or more objective(s).

defined (way of working)

In the context of standards, ‘defined’ denotes a documented way of working which people are expected to use. This can apply to any aspect of a governance or management framework for example processes, codes of practice, methods, templates, tools and guides.

E

established (way of working)

In the context of standards, ‘established’ denotes a way of working that is implemented and used throughout the organisation. This can apply to any aspect of a governance or management framework for example processes, codes of practice, methods, templates, tools and guides.

G

gate

A decision point carried out as part of formal governance, at significant points in the life cycle to ensure that the decision to invest as stated in an agreed business case and plans is, and remains, valid.

governance

Governance defines relationships and the distribution of rights and responsibilities among those who work with and in the organisation. It determines the rules and procedures through which the organisation’s objectives are set and provides the means of attaining those objectives and monitoring performance.

governance and management framework

A governance and management framework sets out the authority limits, decision making roles and rules, degrees of autonomy, assurance needs, reporting structure, accountabilities and roles, and the appropriate management practices and associated documentation needed to meet this standard.

government major project

A central government funded project or programme that requires HM Treasury approval during its life, as set out in Delegated Authority letters, or is otherwise of special interest to the government. A government major project is listed in the Government Major Projects Portfolio (GMPP).

Government Major Projects Portfolio (GMPP)

The portfolio of the Government’s largest, complex, innovative, risky and ambitious projects that have been agreed by the Infrastructure and Projects Authority, HMT and departments and are delivering the government’s main policy initiatives.

I

integrated assurance and approval plan (IAAP)

The planning, co-ordination and provision of assurance activities and approval points throughout the ‘policy to delivery’ life cycle, proportionate to levels of project cost and risk. From Treasury approvals process for programmes and projects.

integrated assurance strategy (IAS)

The integrated assurance strategy sets the strategic requirements for assurance provision to ensure agreed and consistent standards across an organisation’s portfolio of major projects.

issue

A relevant event that has happened, was not planned and requires management action. It could be a problem, benefit, query, concern, change request or risk that has occurred.

L

life cycle

The life cycle provides a phased structure for governing the work and underpinning the delivery plan, from start to finish. Life cycles can be applied to a portfolio, service, product, system, programme or project.

O

organisation

In the context of government functional standards, ‘organisation’ is the generic term used to describe a government department, arm’s length body, or any other entity, which is identified as being within the scope of the functional standard.

other related work (project delivery)

In the context of project delivery, other related work comprises work within a portfolio or programme which is not managed as a project.

Note: examples of other related work are support services (such as for finance and human resources, support offices and specialist information and engineering offices), ongoing improvement initiatives not run as projects, service delivery and business as usual operations

outcome

The result of change, normally affecting real-world behaviour or circumstances. Outcomes are desired when a change is conceived. Outcomes are achieved as a result of the activities undertaken to effect the change; they are the manifestation of part or all of the new state conceived in the target operating model.

output

A specialist product (the tangible or intangible artefact) that is produced, constructed or created as a result of a planned activity and handed over to users.

P

plan

A plan sets out how objectives, outcomes and outputs are to be delivered within defined constraints, in accordance with the strategy.

portfolio

A portfolio comprises part or all of an organisation’s investment required to achieve its objectives. Governed through its portfolio (or business) plan, a portfolio comprises work components, such as other portfolios, programmes, projects, other related work and work packages.

portfolio management

Portfolio management is a co-ordinated collection of strategic practices and decisions that together enable the most effective balance of organisational change and business as usual.

portfolio strategy

A collection of top-level strategic information that provides total clarity to all stakeholders regarding the content and long-term objectives of the portfolio.

programme

A programme is a unique, temporary, flexible organisation created to co-ordinate, direct and oversee the implementation of a set of projects and other related work components to deliver outcomes and benefits related to a set of strategic objectives.

project

A project is a unique temporary management environment, undertaken in stages, created for the purpose of delivering one or more business products or outcomes.

project delivery

Collectively, portfolio, programme and project management are referred to in government as ‘project delivery’.

Q

quality

The degree to which the features and inherent or assigned characteristics of a product, person, process, service and/or system bear on its ability to show that it meets expectations or stated needs, requirements or specification.

quality assurance

The planned systematic process that will be used to provide confidence that outputs will match their defined quality criteria.

quality control

The process of monitoring specific project results to determine whether they comply with relevant standards and of identifying ways to eliminate causes of unsatisfactory performance.

R

residual risk

The risk remaining after the risk response has been applied.

responsible (person)

Someone who is responsible has some control over or care for an action, or the obligation to do something as part of a wider job role.

Note: a responsible person is responsible to an accountable person, or themselves if they are the accountable person.

risk

The effect of uncertainty on objectives. Risk is usually expressed in terms of causes, potential events, and their consequences

• a cause is an element which alone or in combination has the potential to give rise to risk
• an event is an occurrence or change of a set of circumstances and can be something that is expected which does not happen or something that is not expected which does happen. Events can have multiple causes and consequences and can affect multiple objectives
• the consequences should the event happen – consequences are the outcome of an event affecting objectives, which can be certain or uncertain, can have positive or negative direct of indirect effects on objectives, can be expressed qualitatively or quantitatively, and can escalate through cascading and cumulative effects

risk appetite

The amount of risk the organisation, or subset of it, is willing to accept. risk tolerance The threshold levels of risk exposure that, with appropriate approvals, can be exceeded, but which when exceeded will trigger some form of response (for example, reporting the situation to senior management for action).

S

senior responsible owner (SRO)

The individual accountable to the sponsoring body for a programme or project meeting its objectives, delivering the required outcomes and realising the required benefits.

Note: the senior responsible owner owns the business case and is accountable for governance.

Note: the sponsoring body could be a group or individual.

Note: the senior responsible owner of a government major project is ultimately accountable to Parliament.

stage (project delivery)

In the context of project delivery, a stage is a subdivision of a project life cycle.

stakeholder

Any individual, group or organisation that can affect or be affected by, or perceive itself to be affected by an initiative (programme, project, activity, risk).

strategy

A strategy outlines longer term objectives, outcomes and outputs, and the means to achieve them, to inform future decisions and planning.

T

target operating model

A model of the future organisation, its working practices and processes, the information it requires and the technology that supports its operations.

Note: it is often called a blueprint.

termination

Termination is the premature closure of a work component because it is no longer needed or viable, or because the risks associated with it have become unacceptably high.

tolerance

The permissible deviation above and below a plan’s target for time and cost without escalating the deviation to the next level of management. There can also be tolerance levels for quality, scope, benefit and risk. Tolerance is applied at project, stage and team levels.

tranche (project delivery)

In the context of project delivery, a tranche is a subdivision of a programme designed to enable an incremental approach to delivery of outputs, outcomes and benefits.

transformation

A distinct change to the way an organisation conducts all or part of its business.

two-way traceability

The ability to trace both forward and backward (for example, from requirement to an element of the solution and from the solution element back to requirement). It can also be applied in other areas, such as to output-outcome-benefits mapping, and solution-plan mapping.

V

validation

An activity that ensures a solution (or part of) meets the needs of the business. Validation ensures that business requirements are met even though these might have changed since the original design.

value for money

Value for money is a balanced judgment based on the benefit cost ratio which brings together social costs and benefits including public sector costs over the entire life of a proposal, together with decisively significant unquantified deliverables, and unmonetised risks and uncertainties, to deliver a proposal’s objectives.

verification

An activity that ensures that a solution (or part of) is complete, accurate, reliable and matches its design specification.

W

work component

A defined and managed part of a portfolio, such as a lower-level portfolio, programme, project, other related work, or work package.

work package

A group of related activities that have a defined scope, deliverable, timescale and cost, contributing to the required outputs and outcomes.

This figure shows the typical activities in the reference life cycle, mandated for government major projects and recommended for others, with the gates, stages, assurance reviews and business cases indicated in the appropriate places.

This project delivery functional standard states in clause 6.3 that a phased approach is taken but the standard does not define the number of the phases, their names nor how they should be applied in each case. This annex has two examples of how the reference life cycle in Annex C can be tailored to reflect different needs and circumstances.

An example life cycle covering the full extent of operations and the disposal of the outputs at the end. The phases could be managed as a project (in stages) or programme (in tranches) depending on the context. This type of life cycle is sometimes called a product life cycle, system life cycle or asset life cycle.

An example project life cycle for a project which uses an agile approach as the primary delivery methodology. The number and types of business case, assurance reviews and project stages can differ from project to project to reflect the context, nature and complexity of the work and the need for appropriate and proportionate governance.