Government 002: Project delivery

5.1 Purpose of the portfolio management

Portfolio management is a coordinated set of practices and decisions that together enable the most effective balance of organizational changes and act as usual while remaining inside a specific funding envelope. The management briefcase should form an integral part of the organization's business planning and control activities. The director and portfolio manager should: • align investments with government policy and department strategy • maximize the benefits realized by the portfolio as a whole • balance the portfolio to cover short-term and long-term goals • provide risk across the portfolio as part of the organization's risk appetite • optimize the organization's opportunities and the ability to provide a portfolio can be provided • ensure that those affected by the portfolio performance are able to accept on changes • optimize the use of funds and resources, keeping in mind the associated risks.

5.2 Portfolio management structure

The portfolio management framework, definition and management of the portfolio will be defined and communicated to the relevant stakeholders. The portfolio management framework should include: • authority and decision-making roles and processes, including, but not limited to, management (see section 4), identifying and messaging potential work items, categorizing, prioritizing and starting a new job, allocating resources and funds, and issuing breakdown • roles and responsibilities, processes, methods, techniques, guidelines, templates and tools • types of work components to be included in the portfolio along with criteria for identifying them • criteria and techniques for categorizing and selecting portfolio work components • planning horizons used and how often the plan should be Evaluated • reporting framework. The portfolio management framework should align and work with: • organization management framework and decision-making authorities • other organizational processes and practices, such as strategic and policy development, business planning, finance, performance reporting, capabilities and capacity management, corporate risk management and communication Record portfolio work components should be updated, including by each work component: component type; Responsible persons; status (for example: proposed, in progress, suspended, completed, completed); position in the portfolio hierarchy; significant interdependencies between components under different higher responsible owners; indicator that indicates whether the component should be reported as part of major government projects Portfolio. Additional data may be included for management, analysis and reporting goals. Note: The portfolio management structure can be tailored to portfolio management [Annex A, 24]. Further guidance is provided in ISO 21504 [Annex A, 33]. Note: Portfolio management responsibilities can be assigned as each department sees fit. For example, planning or management integrated with business as a set of sub-portfolios. The organizational group's portfolio of activities may provide other services, such as provided by the program management office (see 4.4.7), including methods, advice, resources, or tool support.

5.3 Practice Portfolio Management

5.3.1 Portfolio definition and planning

The portfolio as a whole should be planned in line with the management framework in order to meet the objective mentioned in section 5.1. When planning a portfolio: • government policy, strategic goals, context and priorities should be understood along with the current status of the portfolio and its work items - the strategy can be developed top-down, from policy, or it can come out of action experience • potential new work items should be categorized and assessed , based on strategic degree alignment, expected benefits, efficient use of funds and risks - stakeholder views should be understood and considered • working components should be prioritized and selected based on evaluation results, taking into account the performance of existing working components • each work item should be identifiable with government policy or departmental objectives • the plan should be compiled of interdependencies identified between the elements inside and outside the portfolio • once approved, the portfolio plan should be baseline and any changes approved by the competent authority

5.3.2 Validation of portfolio goals and strategy

Portfolio objectives and strategy should be reviewed periodically to ensure: • They are still valid and affordable • Relevant programs, projects and other work are undertaken If not approved, corrective action must be taken to change the portfolio strategy and objectives or adjust the portfolio work components.

5.3.3 Monitoring and portfolio delivery analysis

The portfolio as a whole should be monitored and analyzed in relation to: • results and benefit realization • adherence to costs and schedule limit • supply of essential products • availability of finance • current capacity and constraints in the organization and supply chain • current portfolio risk level, including those related to interdependencies • response from injured parties and other stakeholders Stakeholders should be monitored and involved, with new stakeholders and current stakeholders are overestimated. New risks and problems must be identified and the existing ones managed. Action should be taken to ensure that the portfolio meets its goals and reflects any constraints. Existing work components may be identified for rescheduling, rescheduling, or completion. Corrective and preventive actions may result in the need for new work items, re-scoping or termination of work.

5.3.4 Reporting Portfolio Performance

Portfolio performance should be reported against the portfolio plan, including but not limited to finances, benefits, milestones and risk. Additional analysis and comment may be needed to clarify the differences. Reporting should reflect both the achievement date and the forecast of future results.

5.3.5 Approval of Origin Work Components

Identify new work items, identified and approved (as per approved approval process see 4.3 decision making), to begin when indicated in the plan or as required by the organization Priorities Before initiating the portfolio, the manager should confirm the stated objectives in 5.1 are met. an impact assessment on financial, resource or technical capacity is available and that the program / project does not conflict or duplicate other work. See section 6.4 on identifying and initiating a program or project. Note: When approving start of work for a component, problem, or opportunity to be known, although the solution and approach to deployment may not be known

6.1 Program goal and project management

Program and project management is a structured framework for defining and implementing change in an organization. They provide a framework for implementing business strategies and initiatives that enable the government to deliver strategically significant results and benefits. Program and project management includes planning, delegating, monitoring and controlling all aspects of a program or project, and motivating people involved to achieve specific goals within the constraints of time, cost, quality, scope, benefit and risk.

6.2 Program and design of the governance framework

Program and project management A framework that defines how a program or project is to be directed and managed will be defined and communicated. The management framework should include: • authority and decision-making roles and program rules and components, including but not limited to management levels, initiating new work, prioritizing, allocating resources and funds, and broadcasting • roles and responsibilities, processes, methods techniques, guidelines, templates and tools to get used to follow the practices in sections 6 and 7 of this standard The management framework should align with and work with: • the portfolio management framework • other organizational processes and practices, such as those related to finance. Human Resource Management, Performance Reporting, Opportunity and Capability Management, Risk Management and Communication. Note: the management structure can be adapted from the AXELOS best practice guides [Annex A, 21-28], departmental methodologies or, for major courses, projects, can be specially developed.

6.3 Life cycles

The life cycle is a staged structure that regulates work and forms the basis of a plan delivery, from start to finish. The life cycle should be defined and should include approval of the goal / decision points and providing feedback. The program may be broken down into one or more phases of tranches and may cover the lifetime of a product, service or system (see Figure 3). The project consists of stages that are preceded by a gate (decision point) to approve the beginning of the next implement and allocate resources and funding. The project life cycle should be defined depending on the circumstances. The number of gates and stages, types of certifying review, and the form of the business case should be chosen to ensure proper management to the circumstances, with simpler projects having fewer stages (minimum of two) and more risky projects with more stages. See Figure 4 and Annex D For each gateway, define: • Go decision criteria • Decision makers • Who to consult • Required type of pre-decision assurance review (see 4.2) Criteria should include the following: and strategy and is still needed • the business case is acceptable • the risks have been identified and acceptable or can be mitigated • the solution is (or likely will be) acceptable • there are funds and resources to complete the work and support any outcomes • there is a plan for the next step and outline plan for remainder of Work A gate decision may result in approval to proceed, request to change work, or postponement or termination of the project. Model project life cycles can be developed to undertake specific types of projects. Note: Appendix D contains a detailed example of the life circle design. Annex E covers the smooth delivery of an example

Figure 3 Sample program life cycle showing tranches, decisions and verification reviews from section 4 and their relationship to practice in sections 6 and 7 - see original document

Figure 4 Sample project life cycle with steps, gates and verification reviews from section 4 and their relationship to practices in sections 6 and 7 - see original document

Note: Project phases are called phases (PRINCE2® [22]). The stages may reflect the approach taken, e.g. developed using an agile approach such as discovery, alpha, beta (private); beta (public) or in a "waterfall", eg as analysis, design, development, testing, implementation. Further details and examples of the project life cycle are provided in Annexes D and E.

6.4 Management practice program and design

6.4.1. Identification - policy

The identification of the program or project ensures for which the policy or other purpose for the work is stated and likely to be realistic before the team is mobilized and the funds and resources involved. The senior responsible owner is the designated one. Potential team members and subject matter experts should be identified and involved in policy formulation ensure deliver ability. Before submitting a program or project for approval, the senior responsible owner should ensure: • The vision and rationale for the program or project, along with any strategic assumptions, is successful. documented in the program or project description • Policy and decision makers have sought advice from experienced professionals regarding reach ability and risk • Appropriate attestation reviews have been performed (see section 4.2) - for a new policy or business change initiative that could result in a government major project. The review should be a project validation review or the equivalent Policy and goals can evolve and change as work progresses.

6.4.2 Managerial

Provides program or project management further strategic alignment and relevance to the prevailing business context. The Senior Accountable Owner provides a solution that meets government policy and / or meets the needs of the company and represents value for money. The senior accountable owner ensures that you guide and make decisions about the future of the program or project, taking into account changes in overall policy, the social, environmental or technological context, and prevailing risks. This should include ensuring the program or project remains reasonable and verifying and approvals (such as at gates and for closure) are timely and corrective and preventive actions taken as needed. The senior accountable owner should deal with decisions in excess of their powers delegated to the relevant decision makers in line with the governance framework (see section 4.3). Note: see also section 4.4.4, role of senior citizen responsible owner.

6.4.3 Initiating

Initialization ensures that a program or project is set up, defined and planned, and that the team is mobilized and understands what is required. A senior accountable owner confirms there is a real need for a targeted policy or business, communicate the vision and goals along with strategic assumptions, and establish criteria for measuring success. The program or project manager should mobilize the team and facilities required to undertake the work and define the management framework used (see 6.2). The team should understand the requirement, assumptions, constraints and risks, and should explore different solutions, delivery methods and delivery options. A work plan will be developed, including the approaches to be used for the specialist work, taking into account lessons learned from previous relevant work (see 7.2.1). Initial rationale for the project should be documented in a strategic business or program outline (or equivalent). Note: "Initialization" ensures that the program or project runs in a controlled manner. Choosing a solution may require a discovery phase (agile) or a number of investigative steps to be undertaken. See the 6.3 circle of life.

6.4.4 Managers

The program or project manager should provide the appropriate team (including vendors) and facilities are in place. New tranches, milestones or work should be planned and checked before approval (see section 6.3). Work packages should be initiated and monitored against the plan or product backlog, risks reduced, problems resolved and changes controlled. Lessons should be continuously captured and managed (see section 7.2). The outputs should be developed ready for use (see section 7.3) and stakeholder feedback should continue to be addressed to ensure any business changes are embedded in new ways of working that the desired results are achieved (see section 7.1). Commercial and financial aspects should be addressed (see section 7.4). The ongoing program or project rationale will be monitored and the business case updated as necessary (see section 4.3) in a controlled manner (see 7.2.5).

6.4.5 Delivery management

Supply management ensures work to development results and results are under control: • work should be defined, planned, managed in work packages or sprints (see section 7.2.1) • risks, problems, change requests and stakeholder views should be addressed • providers should be managed (see section 7.4) • lessons should be continuously captured and managed (see section 7.2) • results should be developed using methodologies and techniques that are proportionate and appropriate and quality verified (see section 7.3)

6.4.6 Closing

The program or project will close in a controlled manner. Project closure may occur when the project is completed as planned or prematurely terminated: • delivering results and achievements, past results should be Confirmed • responsibility for ongoing risks, problems, activities and tracking of benefits should be passed on to and approved by the appropriate business body • documentation and information should be securely archived (see 7.2.7) • team and any temporary facilities should be demobilized The program or project manager from the team and key stakeholders undertake a closure review, which should include a performance evaluation in relation to the plan and the extent to which the goals are being met. New lessons should be captured and analyzed along with those identified while working; meaningful lessons should be captured and shared (see section 7.3.6). Post-closure inspection plans should be agreed by the responsible responsible owner (see section 4.2). Interested parties will be informed of the closure. Note: Termination may occur because the project is no longer needed and is no longer viable, and the risks have become unacceptably high due to this.

6.4.7 Review of the results

The performance review determines the degree of success of a program or project. The senior responsible owner should ensure that a review has been conducted to assess the extent to which benefits delivery and operational performance have been achieved and are likely to continue to meet the goals and expectations set by the suitcase industry. Lessons must be captured and communicated.

This section covers the practice management to be undertaken throughout the delivery. These practices are the responsibility of the respective manager for: for example portfolio manager for a portfolio, project manager or team work package manager and can be delegated to portfolio, program or project support office manager (see section 4.4, roles). All support practices should be managed and monitored (see 6.4.4) using a defined approach that is improved through use. Note: guidance can be found in the AXELOS guides [21–28]. In addition, APM and PMI knowledge bodies [36–40] as well as UK and International standards can be referenced [29–35].

7.1 Benefits and Changes

Business and change support practices ensure the successful implementation of the project by engaging with stakeholders and users and embedding the required business change or new service within the company. Aspects of business change will be taken into account and planned from the beginning of the program or project and addressed throughout the circle of life.

7.1.1 Benefit Management

Benefit management ensures the benefits are realized in practice. Relevant stakeholder expectations should be understood as the benefits that need to be realized by the solution development team. Benefits should be identified, analyzed, defined, planned and tracked. The benefits should be assessed against a range of options before: the solution is selected (see 7.3.3) and incorporated in the business case (see 4.3) where potentially conflicting pressures such as performance, scope, time, risk, cost, benefits are balanced . Each discrete benefit should be assigned to the benefit owner who has the responsibility of forecasting and monitoring it. Benefits should be reassessed over the course of your job as new benefits may arise as your work progresses and expectations may change. Benefit trigger points should be included in your plans. Once launched, the actual realization of the benefits should be tracked against the plan. There should be two-way traceability between benefits, outcome, solution, products, requirements and objectives (see Figure 5). Note: With benefit mapping you may get used to demonstrating traceability.

7.1.2 Change management

The goal of change management is to prepare, equip and support organizations and individuals (eg users, citizens) to change their approach and where appropriate behavior. All programs and projects should have a vision and plan for the future state, assess the current state of target groups, use appropriate design techniques, and manage required changes continuously, assess target groups' readiness to accept changes and track progress towards achieving the future state. Milestones representing the achievement of the results should be included in the plan. Once an operational approach has been transformed, it should be monitored to ensure that behaviors and practices are not undone.

7.1.3 Stakeholder involvement

Stakeholder engagement ensures the needs and concerns of stakeholders are addressed sufficiently to enable the goals met. A stakeholder is any person, group or organization that can influence, be affected by, or perceived to be influenced by, an initiative (program, project, activity). Stakeholders should be identified and their interests and expectations understood. A plan should be developed on how to involve them in a coordinated and appropriate manner. The engagement plan should be implemented, monitored and updated to reflect emerging stakeholders and changes to the position of current stakeholders. Stakeholder attitudes should be assessed, updated and validated throughout the work. Note: Depending on the stakeholder engagement, this can be done in a number of ways, including face-to-face personal contact, meetings, or collaborative working approaches such as agile.

7.1.4 Communication

Communication ensures interactions with stakeholders are effective and likely to contribute to a successful job delivery. Communication should be designed and coordinated to ensure that the right messages are addressed to the right audience at the right time and in a manner that is acceptable to the audience. Communication should be planned to match the stakeholder needs and includes feedback mechanisms and performance measures. The impact of communication should be assessed and, where appropriate, replied to. The communication plan should be adjusted as needed to achieve a successful change. Note: Depending on the stakeholders, engagement may be through press releases, news channels, advertisements, posters, social media, websites, leaflets.

7.2 Control

Control control practices ensure that work is planned and corrective and preventive actions are taken to ensure delivery in line with the baseline. Work should be defined, planned, monitored and controlled. Component job managers should be set as acceptable tolerances in which there is no escalation required to the next level of management. Tolerance levels may include, but are not limited to, scope, efficiency, time, cost, quality, benefit, and risk.

7.2.1 Planning

Planning ensures results and results are likely to be delivered within the defined constraints (including scope, efficiency, time, cost, resources, risk) to achieve goals and realize required benefits. Planning should be a collaborative activity, possibly involving team members in planning the work. Estimates should be substantiated by evidence or experience such as a forecasting reference class, consensus or experience from previous work. Plans can be designed for immediate use or created as a contingency plan to respond to known threats. The plan should be based on a hierarchy showing the position of each item of the work hierarchy (see Figure 2). There should be one point of responsibility for each ingredient and activity. Plans should be visible at different levels of the hierarchy and show the appropriate level of detail to meet the needs of plan viewers. Depending on the level of the plan (portfolio, program, project, or work package), the plan may contain benefit forecasts (if applicable), milestones, activities, schedule, costs and resources, with associated assumptions, constraints, critical paths, and risks. Relationships between activities and other work elements (such as programs and projects) should be defined. The plan should include and authorize assurance and decision-making activities (see sections 4 and 6.3). Note: the plan can be contained in a single document or information source or disseminated in a number of sources. Note: You can use many different hierarchies to provide different plan perspectives such as product breakdown, cost breakdown, epic, and user history. Planning can be iterative and progressive through the life cycle of a work item, with more detailed information for the near future than for more distant work. The scope can be refined and clarified as the work progresses to develop a plan that can be delivered to address an acceptable level of risk. The plan may include an indication of the current level of assurance using for example scopes or confidence indicators. Once approved, the plans will be baseline and progress will be monitored and analyzed regularly. Forecasts should take into account current progress and current assumptions and risks. Plans should be particularly updated ahead of important decision points such as project gates. Any changes to the baseline should be made in a controlled manner outside the agreed tolerances (see 7.2.5).

7.2.2 Resources, Capacity and Management Capabilities

Resources, capacity and management capabilities are balanced by the supply and demand for the appropriate resources (such as people, equipment, materials, and facilities) to be deployed when needed. Resources can come from government, through recruiting, or from the supply chain. A comprehensive overview of future resource needs should be developed and maintained, with possible gaps identified and addressed. Resources should be acquired or developed to meet planned needs. If insufficient resources are available, work should be rescheduled to reflect constraints. Business continuity should be in place in case of loss of critical resources (see 7.4.2). Note: "adequate resources" means, for materials, equipment and supplies, the required quantity with the appropriate specification. For people, this means the right skills, competences and competences to take up a job. See [13]. 7.2.3 Reporting Reporting ensures that management teams are aware of the current status and prospects, especially with respect to the likelihood of achieving goals. A reporting framework must be developed to meet the needs of a specific audience report in a timely manner. The report should highlight the progress so far, whether the current scope of work is likely to be completed, plan, the risks and problems prevailing, and any decisions or directions required. Relevant milestones and performance indicators should be included in the report. The performance indicators should reflect the delivery method used (eg backlog for agile delivery). Each report should specify a period or date the report is associated with a date and date the report was published or created live. The form of the report should be appropriate and proportionate to the reported work on (eg, Gantt, slippage, visibility graph, burn down) and reported roles. Major government projects are reported every year, with quarterly updates in a format defined by the Authority's infrastructure and projects and in line with the Government's Transparency Policy [15]. Note: Reporting is about information flowing and between portfolio, program, project, and work package teams. Information flow with wider stakeholders is discussed in 7.1.4 Communication 7.2.4 Risk and problem management Ensures risk and problem management ensures goals are more likely to be achieved, given the unexpected uncertainty of the event and threats or the chances of undertaking work with the solution, and external. Risk is the uncertainty of the outcome (positive or negative). A problem is a significant event that has happened (or is inevitable), has not been planned and requires management action. There could be a problem, benefit, inquiry, concern, change to request, or risk that has occurred. Risks and problems should be: • identified, assigned owner and assessed taking into account the impact and timing of triggering the cause (proximity) • responded by mitigating actions to eliminate, reduce or avoid consequences or reduce the possibility of occurrence; risk can be recognized • monitored to resolution and closed when no longer valid; Residual and possible secondary risks should be identified and responded to. Risk controls should be reviewed to ensure they remain effective. Risk should be managed individually risk and collectively. There may be a case of maintaining the appropriate level of hierarchy in the work and authorization if needed. Overall risk should be managed within the framework of the risk appetite and tolerance of the organization. The risk may be related to: • the likelihood of an event occurring and its potential consequences • an unknown variable to be assumed (for example number of users, inflation) what to understand, expressed in the business case and, where possible, quantified using cost benefit analysis Circumstances in which the work will no longer be feasible or an appropriate solution should be established using such techniques as simulation, contingency scenarios and sensitivity analysis. Risks and problems that the owner cannot decide should be escalated or reassigned as necessary. The work component hierarchy (see Figure 2) can serve as the basis for an escalation or reassignment of risk. Risk owners may be outside the formal hierarchy but should be accountable to the person in the work component management structure. Note: You can find guidelines on risk management in the Orange Book [6] and risk management in government [7].

7.2.5 Change control

Change control only provides the benefits or necessary changes to the baseline it's implemented. The changes can come from any stakeholder, including developer policies, executive management, end users, suppliers, or team members. Alternatively, the change may be due to a risk or a problem that cannot be resolved. Criteria should be defined to: • define what aspects of the work should be controlled by changes • direct which people or groups have the authority to approve the change (see section 4.3)

Figure 6 Relationship between risks, problems and changes - see original document

Change requests should be logged, identified and defined. The impact of the change should be assessed in terms of the impact on the business case, objectives, benefits, scope, resources, time, costs, quality and risk. An implementation plan should be developed prior to receiving approval to implement the change. The decision must be communicated to all interested parties. After the change has been included in the baseline, the plan has been updated and the affected information, the change request should be closed. Changes to systems / groups of related products (products) should be controlled through configuration management.

7.2.6 Configuration management

Configuration management is a term used to describe the management of a group of products or items that work together to manage and deliver a solution, service or system, produced internally or by a vendor. Configuration management is used to make sure that the components of the solution work together, are identified by status and version, and that the composition of the higher groups of these products are compatible and known at all times. Configuration management should include: • scope planning and configuration management, including configuration baseline control • billing of configuration status and reporting to ensure those in need are informed • accuracy verification configuration records (configuration revision) Note: products subject to configuration management may include these manufactured by suppliers and tools used internally during design, development or fabrication ie solutions and management results. Note: This practice is essential to most engineering or technical solutions, but can be applied to technical elements such as processes, operating instructions, and instructions. Different sectors may have different names such as parts or resource management.

7.2.7 Information management

Information management ensures that all the necessary information (physical or electronic) is available and reliable to work and make decisions. The information to be managed should be defined. This may include solution information and development, plans, progress reviews, reviews and audits, contracts, reports and communication. Information should be recorded on receipt, validated, validated, securely stored, distributed and retrievable by those who need it. Business continuity measures should be put in place in the event of a destructive incident. New information sets, such as documents, should be checked, approved, version controlled and, when no longer required, withdrawn and archived. The status, security, classification and origin of the information should be clear. Information should be retained to meet statutory and contractual requirements. Configuration management may be required to ensure the integrity of a group of related information (see 7.2.6). Government 007, Security must be respected. Note: Information management may include web content management, document management, document management, digital asset management, science management, information building modeling and content systems. Note: tips on how to handle information can be found in [8-10]

7.3 Quality

Quality support practices determine the degree to which the features and inherent or assigned features of an output or solution (whether the product, person, process, service and / or system) meet the expectations or identified needs, requirements and specifications. Actively manages quality to maximize the probability of success. The methodology or process for undertaking work should be defined and appropriate to the outputs. People should be trained, informed, and competent to undertake the work assigned to them. Note as well as AXELOS best practice guides, standards and knowledge resources, requirements guidance, design, verification and validation can be found in CMMI-DEV [40] and ISO 15288 [35].

7.3.1 Quality management

Quality management ensures that the results are fit for purpose. The management framework should include: • quality assurance to ensure that the results match their specified quality criteria • quality control to monitor specific results to determine compliance with specific projects and identify ways to eliminate the causes of unsatisfactory performance Note: the quality of the solution depends on choosing the right project and developing methodologies. There are different approaches that are appropriate in different circumstances, for example an iterative agile approach to digital content delivery service [11].

7.3.2 User needs and requirements

Requirements management ensures the needs and stakeholders are understood and considered during the solution development. Requirements should be refined, developed (for example as agile epics and user stories) and evolve along with the design until a workable product is defined and agreed upon. To fully be able to need multiple iterations to understand the requirements. A common understanding of the results for all phases of the solution lifecycle (including development, life and disposal) should be agreed between the applicants for the work and the people doing it. This should include any applicable statutory, regulatory or other restrictions. For them, the requirements of the impact on the development and use of the results and subsequent results, such as society, end-users, operations and maintenance personnel, programmers, builders and manufacturers should be specified. Requirements should be clearly identifiable, current, mutually consistent, understandable, unambiguous, prioritized and approved. There should be two-way traceability between requirements and design elements. Changes in requirements should be controlled, and changes should be aligned with the vision and goals of the work item. Note: Traceability can be registered using Configuration Management.

7.3.3 Solution design

The design ensures that the outputs meet the requirements and achieve the desired results and benefits and represent value for money. Design can be sequential, incremental, iterative, or agile. Solution design can evolve as requirements are developed and design progresses. The solution design (or plan) should include all outputs needed to achieve the desired results, including but not limited to people, software, hardware, maintenance operations and products, manufacturing, safety, information, organization design, supply chain, performance characteristics and desired behaviors. The solution should be sufficiently defined to allow parts of it to be verified as correct. There should be two-way traceability between design elements and plan. The design team should consider the range of solutions (design approaches, design concepts or preliminary designs) that potentially meet the requirements and recommend a solution for implementation. Consider the entire solution as it progresses to its components, including those undertaken and implemented by suppliers. Interactions between components and the operating environment should be known and taken into account.

7.3.4 Solution development and integration

The development and integration of solutions ensures that the solution is built in a specific way, that all components that make up the solution work together as part of the operation environment. Working methods and processes should be defined along with how the various elements of the designed solutions are integrated and work as a whole. A strategy should be developed to identify the approach that should be adopted to sequencing, delivering, and integrating solution components, including any special environment or equipment required.

7.3.5 Design verification and validation as required

Verification validates and the solution (or part of the solution) matches the specific project to confirm it. It should be designed to detect faults or failures. The validation ensures that the correct problem is addressed, and the solution is likely to meet the requirements when operated 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 can be iterative with the solution, design and requirements evolving as work progresses. The methods used for professionals The work should include an appropriate approach and planned activities for verification and validation. Note: Verification and validation methodologies may include, but are not limited to, prototyping, simulation, inspection, show-and-tell, analysis, demonstration, testing, trial or pilot testing, and sampling.

7.3.6 Learning from Experience

Learning from experience avoids repeating the same mistakes and helps you spread improved practices for the benefit of present and future work. At the beginning of the work, the involved and key stakeholders should identify and apply relevant conclusions from previous experiences when planning the work. Throughout the life cycle, lessons should be continuously captured, evaluated and action should be taken to reduce delivery risks and facilitate continual improvement of the final products and services. The organization of the leader (including the body under market conditions) and the owners of standards, processes, methods, guidelines, tools and training should update their sources of knowledge and communicate learning accordingly.

7.3.7 Induction and Training Program and Design Team

Induction and training ensures team members work efficiently as quickly as possible as practical as becoming familiar with the context of a program or project and its operating procedures. The induction should include, inter alia, ensuring the necessary equipment is made available, an overview of the work, the role is undertaken, the necessary processes are observed and required training, and the granting of adequate security access. Training should cover, inter alia, defining the training strategy, analyzing training needs, defining, developing and conducting briefings / courses, planning, delivering and monitoring a training event.

7.4 Commercial and financial

Commercial and financial support practices ensure government policy on commercial and financial management to be followed, and managers should have provided the necessary information to take on their roles.

7.4.1 Finance

Financial management ensures the efficiency and effective management of money (funds) to achieve the goals of the organization. The level of funding needed should be as agreed in the short and long term per portfolio, program or project, including any subsequent use or operating costs. Funding sources should be secured. A governance framework should be defined, including financial accountability, delegation levels, approval and monitoring. Financial reporting should be credible and communicated to decision makers and component managers in a timely manner. Government 006, Finance should be respected.

7.4.2 Acquisition

Sourcing provides products or services purchased as part of a job sourcing or the development of the results is of adequate quality, represent value for money, and can be supplied shielded at an acceptable level of risk. An appropriate contract strategy and sourcing must identify packages, suppliers selected based on defined criteria, and formally agreed contracts. Contracts should be designed to reflect the type and method of delivery and the reliability of the supply chain. The scope of the contracts should include all necessary documentation and required tools to support the service or product. Government 008, Commercial, sourcing must be followed.

7.4.3 Contract management

Contract management ensures any products or services purchased as part of the resource sourcing work or development of results are of the required quality and delivered when needed. The management team should comply with the contractual obligations (as a customer), including payments to suppliers. Supplier's performance and quality should be monitored and accepted after verification against contractual requirements. Government 008, Commercial, contract management should be followed

Government references

1 HM Treasury (2015), Managing Public Money

2) Cabinet Office (2017), Cabinet Office Controls Note: Expense control guidelines help governments reduce spending waste and help reduce fiscal deficits.

3) Infrastructure and Project Authority, Certification Toolkit Note: The guidancekit includes an integrated toolkit to provide verification of Gateway reviews (1 to 5), approval and assurance plans, risk potential.

4 Cabinet office, SRO information note: relevant documentation Note: A set of guidelines for SRO when projects undergo certification reviews for the Office of Infrastructure and Projects.

5 HM Treasury (2016), The Green Book: Appraisal and Evaluation in Government Government Note: Treasury guidance for public sector bodies on assessing proposals before adopting funding for a policy, program or project.

6 HM Treasury (2013), The Orange Book Management of Risk: Principles and Concepts

7 Cabinet (2017), Risk management in government: a framework

8 HMG Information Provision Standards

9 Cabinet, National Security and Intelligence Bureau and the Government Occupation of Security (2014), Framework of security policy

10 Guide to Providing Information and Data Processing

11 Government Digital Service Standards Note: an information pack that includes a digital service standard, a service manual (how-to guidelines for researching, designing, and building services that conform to the digital service standard), and a technology code from Practice (a standard that you must meet, to get permission to spend money on a technology or service).

12 Cabinet Office (2011), Guide to Implementing Integrated Inspection and Approvals

13 Cabinet Office (2017), Project Delivery Capability Framework

14 HM Treasury (2016), Treasury approval process for programs and projects Note: HM treasury guidelines for the Treasury Approval Point (TAP) process and arrangements for the control and approval of major projects and program expenditure beyond Delegated Authority (DAL) limits set by the Treasury .

15 Transparency policy in the Large Government Project Portfolio (GMPP) and departmental layoff guidelines

16 HM Treasury (2012), Assurance Frameworks

17 HM Treasury (2017), Accounting Officer System Statement

18 HM Treasury (2017), Making a Accountant Assessment

19 not used

20 not used Publications aXeloS Best Practice - see footnote 1

21 Managing Successful Projects with PRINCE2, 6th Edition (2017)

22 Directing Successful Projects with PRINCE2, first release (2009)

23 Managing Successful Programs (MSP®), 4th edition (2011)

24 Portfolio management, first edition (2011)

25 Risk Management, Third Edition (2010)

26 Portfolio, program and design offices, second edition (2014)

27 Portfolio, program and project maturity model (P3M3)

28 PRINCE2 Agile, first edition (2015) British and international standards - see footnote 2

29 BS6079 Part 1: 2010 Project Management Principles and Guidelines

30 BS6079 Part 2: 2000 Project Management Part 2: Vocabulary

31 BS ISO 21500: 2012 Guidelines for project management

32 ISO 21503: 2017 Guidelines for program management

33 BS ISO 21504: 2015 Project, program and portfolio management: Guidelines for portfolio management

34 ISO 21505: 2017 Project, program and portfolio management: Guidelines for management

35 BS ISO / IEC / IEEE 15288: 2015 Systems and software engineering: System life cycle processes Professional organizations - see footnote 3

36 APM Knowledge Base, 6th edition (includes portfolio, program and project management)

37 The Body of Knowledge Project Management Guide, Fifth Edition, PMI, 2013

38 Program management standard, third edition, PMI, 2013

39 Portfolio management standard, third edition, PMI, 2013

40 CMMI® for Development, version 1.3, SEI Note 1: AXELOS is a UK government company that has taken over the management of the company Best Practice Guides from the former Government Trade Bureau at the Cabinet Office. Guides are available by subscription or individual purchase. These guides provide recommended methods for implementing government projects. Note 2: British and International Standards provide additional information and are available.

Note 3: The Association for Project Management (APM) is a chartered professional organization in the UK. The Project Management Institute (PMI) is based in the US and has chapters in the UK. Their testimonials are free online for members or for individual purchase. The Software Engineering Institute is a federally funded research and development center sponsored by the US Department of Defense. Its CMMI material is free to download.

For definitions of portfolio, program, project, other work and work package see section 3. For role definitions see section 4.4 and Appendix C

assurance - Ensuring is a systematic set of actions necessary to ensure this trust - work is controlled, in accordance with the delivery schedule, and is consistent with the department's policy or objectives. Adapted from the AXELOS Common Dictionary.

basic level - Measurement, calculation, or location used as a basis for comparison. In a project, delivery base contexts typically relate to plans and datasets related to a solution (such as requirements base level, project base level). Adapted from the AXELOS Common Dictionary.

design - The plan is a model for the future organization, its working practices and processes, the required information and the underlying technology of the operations. From managing successful programs.

business case - The rationale for an organizational activity (strategic, program, project, or operational) that typically includes benefits, results, time frames, costs, and risks against which continued profitability is tested. Adapted from the AXELOS Common Dictionary.

gateway - A decision point, carried out as part of formal management, at significant points in the life cycle to ensure that the investment decision is in accordance with the established business case and plans are and will remain valid. Adapted from the AXELOS Common Dictionary.

management - Management determines the relationships and the distribution of rights and obligations among those who work with and in the organization. It defines the policies and procedures by which the organization's goals are established and provides a means of achieving those goals and monitoring performance. Importantly, it defines where the responsibility rests with the entire organization. From the company management in central government departments: Code of Good Practice. HMT, Cabinet Office (2011). Major Major

Project Portfolio (GMPP) - A portfolio of the largest, complex, innovative, risky and ambitious governments, projects agreed by the Infrastructure and Project Authority, HMT and departments, and implement major government policy initiatives. From the Cabinet Office Controls Glossary. integrated control and approval plan

(IAAP) - Plan, coordinate and provide validation activities and approval points throughout the entire life cycle "from delivery to delivery", proportionate to project cost levels and risk. From the process of approving programs and projects by the State Treasury. integrated control

strategy (IAS) - The integrated certification strategy defines the strategic requirements for the certification of provisions ensuring agreed and consistent standards across the organization's large project portfolio. From the Treasury approval process of programs and design.

Issue - A significant event that has taken place has not been planned and requires action management. It could be a problem, benefit, inquiry, problem, request for change, or a risk Has occurred. From the AXELOS Common Dictionary

circle of life - The life cycle provides a staged work management structure and the foundation of a delivery schedule, from start to finish. Life cycles can be applied to a portfolio, service, product, system, program, or project.

Structure management - Agreed management practices adopted by the organization (or part of an organization), e.g. portfolio management framework, program or design management framework. Adapted from the AXELOS Common Dictionary.

Major Project - A central government funded project or program requiring HM Treasury approval during its lifetime, as specified in the letters of the delegated body or as otherwise of special interest to the government. A major government project is listed in the Government's Major Project Portfolio (GMPP). From which MPA verification review? Cabinet office (2012).

outcome - The result of a change that usually affects behavior or circumstances in the real world. The results are desirable when a change is planned. The results have been achieved as a result of actions taken to make the change; they are the manifestation of some or all of the new state envisaged in the plan. From the AXELOS Common Dictionary.

result - A specialized product (tangible or intangible artifact) that is produced, constructed or created as a result of a planned operation and handed over to users portfolio management Portfolio management is a coordinated set of strategic practices and decisions that together enable the most effective balance of organizational change and business as usual. Adapted from the AXELOS Common Dictionary.

portfolio strategy - A collection of top-level strategic information that provides all stakeholders with complete clarity on the content and long-term goals of the portfolio.

From the AXELOS Common Dictionary.

Project Delivery - Collectively, the management of portfolio, programs, and projects is referred to in the government as "project execution".

quality - The degree to which the characteristics and inherent or assigned characteristics of a product, person, pthe process, service and / or system have the opportunity to demonstrate that it meets the expectations or specific needs, requirements or specifications. From AXELOS Common Dictionary.

Quality Assurance - A planned systematic process that will be used to ensure that the results meet the specified quality criteria. From the AXELOS Common Dictionary.

quality control - The process of monitoring specific project outcomes to determine if they are meeting relevant standards and identifying ways to eliminate the causes of unsatisfactory performance. From the AXELOS Common Dictionary.

residual risk - The risk remaining after applying a risk response.

risk - Uncertainty of the result (positive chance or negative threat). It is a combination of the chance of an event and its consequences. From the management Risk (M_o_R®).

Risk Appetite - The amount of risk that the organization, or a subset of it, is willing to accept. Z Risk management (M_o_R®).

risk tolerance = Threshold levels of risk exposure that may be exceeded with relevant approvals, but which, when exceeded, will trigger some form of response (e.g. reporting situations to senior management for action). From risk management (M_o_R®)

sponsorship group - The driving force behind the program that provides the investment decision and endorsement of the highest level for the rationale and goals of the program. From the AXELOS Common Dictionary.

stakeholder - Any person, group or organization that can influence or perceive itself is influenced by an initiative (program, project, action, risk). From AXELOS Common Dictionary.

termination - Termination is the premature shutdown of a work item because it is no longer needed or profitable, or because the associated risk has become unacceptably high.

tolerance - Allowable deviation above and below the plan target for time and cost without escalating the deviation to the next management level. There may also be tolerance levels of quality, scope, benefit, and risk. Tolerance is applied at the design stage, stage and team levels. Adapted from the AXELOS Common Dictionary.

tranche - A program management term that describes a group of projects built around clear gradual changes in opportunities and benefits. From AXELOS Common Dictionary.

transformation - A marked change in the way an organization conducts all or part of its activities. From managing successful programs.

Bi-directional traceability - Traceability both forwards and backwards. (for example, from requirement to solution element and from solution element back to requirement). It can also be used in other areas such as outcome-result-benefit mapping and solution plan mapping.

validation - An action that provides a solution (or part of it) that meets the needs of the business. Validation ensures that your business requirements are met, even if they may have changed from the original design. Adapted from the AXELOS Common Dictionary.

Verification - An activity that ensures that a solution (or part of it) is complete, accurate, reliable, and conforms to design specifications. Adapted from the AXELOS Common Dictionary.

work component - A defined and managed part of a portfolio, such as a sub-portfolio, program, project, other related work or work package.

Portfolio Manager The Portfolio Manager is accountable to a higher authority for direction and portfolio management, ensuring the realization of the required benefits at an acceptable risk level. He or she is responsible for having a portfolio strategy and plan and should be clear leadership and leadership throughout his life and in particular: • obtain proper management approval of the portfolio strategy and delivery plan • promote a cross-focused culture of the organization, collaboration that works in the interest of the organization as a whole • ensure the evolution of the portfolio to reflect changes in the socio-political environment, policy, strategic goals, business priorities and emerging threats • allocate funds and resources as needed and capacity and capabilities are sufficient to meet the need • ensure portfolio management practices are identified, maintained and kept up-to-date • secure the investment for implementation portfolio management and support systems, tools and environment Note: The role can be supplemented by or supported by a portfolio steering group or an investment committee whose portfolio director may chair. Individual aspects of the role can be assigned to different line managers. Note: Guidelines for portfolio management can be found in the Management of Portfolio [24]. Portfolio Manager The Portfolio Manager is accountable to the Portfolio Manager as a whole to ensure that its work items are sufficient to achieve the goals. Responsibilities include monitoring budget spending, benefit delivery, business change, and risk. The portfolio manager coordinates the effective and efficient operation of portfolio management and ensures the flow of information to decision makers, and in particular: • develops a portfolio strategy and plan to support the organization business plan • identifies portfolio constraints delivery plan • prepares regular portfolio reports for stakeholders and decision makers • provides work-related activities Cases are built consistently and reliably underpinning the entire portfolio, using the same assumptions • Provides investment valuations taken • Provides dependencies between the items in the portfolio that are identified and managed • Leads development and implementation to stakeholder management and communication • Maintains portfolio management up-to-date, identifying and implementing improvements Note: The role may be served by a portfolio progress group or a delivery committee which: the portfolio manager may chair. The individual aspects of the role can be assigned to a different line of managers. Note: Portfolio management guidelines can be found in the Management of Portfolios (MoP®) [24] Senior Responsible Owner (Sro) Ultimately, the senior responsible owner responsible for the program or project is responsible for achieving its goals, projected outcomes, and delivering required benefits. He / she owns the business case and is responsible for all aspects of management. Responsibilities include: • defining and communicating business vision and goals in line with the policy • ensuring a real business need Addressed • ensuring continued profitability • engaging key stakeholders • providing the team with leadership, decisions and directions • ensuring compliance of the delivered business needs solution should be clear, who is responsible for this senior owner is accountable before. Note: the role should be handled by the board program that the SRO should preside over. Note: The SRO may appoint a project sponsor to act on their behalf in relation to a sub-program, project or other program work. Note: for non-GMPP programs or projects, the SRO can be called "sponsor" or "executive body" and may be accountable to a specific group sponsor instead of Parliament. Note: You can find guidelines for the role of SRO in PRINCE2® and Managing Successful Programs (MSP®) [22 and 23]. Program / project manager / director The program / project manager is responsible to the senior responsible owner to establish the management framework and to the day-to-day management of the program / project to deliver the desired results and outputs and enable the required benefits to be realized, including: but not limited to: solutions (plan) designed and business case and prepared plans • definition of approach, responsibilities, scope of work and goals for the team • monitoring, forecasting and reporting overall progress against the plan • resolving risks and problems and controlling changes • delivering the required results and results • vendor monitoring and management performance • engaging and communicating with stakeholders Note: Guidance for program / project manager role can be found in PRINCE2® and Management Successful programs [21 & 23] Program / Project Support Manager iura The management team should be supported in undertaking their roles effectively and efficiently. Support may be provided by one or more physical or virtual structures, ie offices (permanent and / or temporary), which can be centralized or distributed. The services provided may include value-added support as well as administrative functions such as: • providing support to practice management in sections 4, 5 and 6 of this standard • providing specialized online services to support practices in section 7 of this standard • undertaking independent reviews and audits • development, acquisition, selection and management of management and systems support tools • consolidation and analysis of reports • monitoring of resource consumption throughout the organization • providing consulting and coaching, and advising sponsors and managers • maintaining recruitment standards and project development management staff • providing training and assessment Note : Often referred to as the Office of Management or PMO program. Note: Guidance on designing and operating service support can be found in Portfolio, Program and Design Offices [26]. work package manager / team manager The work package manager is responsible to the project manager (or higher level team manager) of the products and results assigned to them (as defined in the work package) to the appropriate quality, schedule and timing acceptable cost. This includes, but is not limited to: • making sure work packages are completed to the required quality, on time and on budget • significant input and review management documentation • planning, monitoring, forecasting and reporting overall progress against the plan • management of solutions risks and problems, escalating any they cannot cope with • controlling changes in their work scope, highlighting any requiring approval Note: guidelines for the role of the team leader can be found in PRINCE2® [21]

This diagram shows an example life cycle of a large government project, with phases, assurance reviews, gates, and business cases as identified in the relevant sections. The life cycle design should be adapted to the specific circumstances - see original document.

This project delivery standard defines: the number of practices needed to succeed outcomes. It specifies why and what for each, but does not specify what the work should look like to be undertaken. Agile is a general term for the scope of the methodology and advocates of agile behavior along with how to undertake the Work. Return shipping is required when developing government digital services, but is not only applicable in other software development situations where the approach comes from.

Return delivery can take place at different levels - see original document

The context in which efficient delivery is applied is important as it affects management. Agile delivery can be taken as a work package within a project (which may be part of the program) or as part of live business as usual within a program or portfolio. This is why the standard has "other work" defined as a working component; not everything has to be managed as a project. Management for agile work, its interface with other work and how it is to be carried out, should be a defined and business case when it is part of a program or project. Work undertaken using agile delivery has yet to be justified and financed. Adequate guarantee, reporting systems and management should be established. You should define roles using ultimately responsible senior accountable owner, but the actual delivery roles used will match the smooth roles, depending on the agile methodology used and the context in which it is happening. The project implementation standard requires: a staged approach to projects, but do not specify what these stages should be. In a project where agile work predominates, the design discovery, alpha, beta, live and retirement phases meet this requirement and comply with paragraph 6.3 and the life cycle in Annex D

Figure e1 Sample project life cycle using agility as a primary delivery methodology - see original document

Note: The number and types of business case, assertion reviews and project phases may differ from project design to reflect the context, nature and complexity of the work