"Each of the delivery steps to create the products occurs in sequence, and the product is made available during or at the end of the project (for example, in a construction project where requirements gathering, and design occur before construction starts)." Ref 1.5.3

Projects are cross-functional. "Projects often work across the usual functional divisions within an organization and sometimes span different organizations." Ref 1.3

The 'ensure continued business justification' principle definition states that "A PRINCE2 project has business justification sufficient to warrant investment to initiate the project and ongoing investment through to successful completion. If it does not, it should be stopped." In addition, PRINCE2 requires "there to be a justifiable reason for starting a project and the justification must remain valid and be revalidated throughout the lifecycle of the project." Ref 2.1

The 'define roles, responsibilities and relationships 'principle relates to defining roles and responsibilities within a structure that engages the business, user and supplier interests."A PRINCE2 project has defined and agreed roles and responsibilities within an organization structure that engages the business, user and supplier stakeholder interests." Ref 2.3

The 'manage by exception' principle reduces time burden for senior management without removing control, by ensuring decisions are made at the right level in the organization. "The implementation of ‘manage by exception ’provides for efficient use of senior management time as it reduces senior managers’ time burden without removing their control. This ensures decisions are made at the right level in the organization." Ref 2.4

The 'manage by exception' principle sets tolerances for the respective level of plan. "A PRINCE2 project establishes limits of delegated authority by defining tolerances for performance against its plans." Ref 2.4

"How PRINCE2 will be applied and tailored for the particular project is captured in the project initiation
documentation." Ref 2.7

The definition of leadership includes "motivating people to achieve a project’s objectives" and "persuading, influencing, and co-creating with a focus on managing key relationships." Ref 3.3

The definition of collaboration is the process of "people from across the project ecosystem working together to achieve the project’s objectives." Ref 3.3

The definition of a stakeholder is ““Any individual, group, or organization that can affect or be affected by (or perceives itself to be affected by) the project.” Ref 3.2.2

"… people within the business who are affected by the project, but do not work within the defined project team" may contribute by "integrating new products into their area of the organization." Ref 3.3.1

Key influencers are "the people the project management team needs to work closest with to ensure the success of the project." Ref 3.2.2

"It is important to understand the competencies and capabilities of the people recruited or assigned to a project and ensure any gaps are identified and mitigations established to cover them, such as upskilling". Ref 3.3.2

The purpose of the change management approach is "To establish the target organizational state required for the project to meet its objectives together with the means by which the business will shift from the current state and through any interim states." Ref 3.2.1

The ‘manage by exception’ principle is applied by the 'people' element by recognizing that "the extent of delegation is often dependent on the level of confidence and trust that exists in the key relationships". Ref 3.5.1

It is the project initiation documentation that "provides the basis for its ongoing management" of the project. Itis the best because it includes the project plan, the business case and the frequency of highlight reporting. Ref 4.3.1

"PRINCE2 projects deliver outputs in the form of products which are used to facilitate changes in an organization or for organizations. These changes create capabilities that lead to outcomes. The outcomes allow the organization(s) to realize the benefits that are explained in the business case for the project" which should align with its business objectives. Ref 5.1

The business case is used "to document the business justification for undertaking a project, based on the estimated costs against the anticipated benefits to be gained and offset by any associated risks." Ref 5.5

An output is defined as "the tangible or intangible deliverable of an activity". Ref 5.1

"All seven aspects of the project's performance targets and their relationships with each other should be considered as part of assessing the business justification, but there will often be trade-offs between different performance aspects. For example, if in developing the project’s product description it is decided that higher quality targets are required, itis likely to impact the cost, time, or sustainability targets." Ref5.2.3

During the 'develop' step of the ‘business case management’ technique, "the provision of a project mandate activates the process of starting up a project. The project mandate is then used as an input to develop the initial business justification for the project documented in the outline business case". Ref 5.3.1.1

The 'ensure continued business justification' principles applied by the 'organizing' practice by "assigning someone from the business to the project executive role who represents the business viewpoint." This results in “the project is able to adapt to changing business needs" and "appropriate decisions are made that align with the business case”. Ref 6.7 tab 6.5

"The purpose of the project management team structure is to define who is involved in the project, their relationships, and how they will work together." Ref 6.5

"PRINCE2 uses the term project team to cover all people required to allocate their time to the project." Ref 6.2.3

“The commissioning party within the business is responsible for providing the project mandate, identifying the executive, defining the project level tolerances within which the project board will work, and determining whether to authorize any potential breach of a project level tolerance.” Ref 6.2.2

During the 'understand the organizational ecosystem 'step, "as a temporary organization, the project approach needs to define how the project will interface and align with the organizational ecosystem where required. There should be clarity on who retains responsibility for issues such as: people management for example, performance management, rewards, advancement and wellbeing." Ref 6.3.1.1

"Plans provide the backbone of the information required to manage a project. When approved, a plan provides a baseline against which progress can be measured and issues assessed. Without a plan, there is no point of reference against which scope, benefits, quality, risks, issues, and progress can be monitored and controlled.” Ref 7.1.2

A work package description is used "to describe how one or more products will be produced and delivered. It is used to pass responsibility for work formally to a team manager or team member." Ref 7.5

A project plan is "a high-level plan showing the major products of the project and when, how, and at what cost they will be delivered." Ref 7.2.2.1

"The PRINCE2 principle of manage by stages addresses the need to keep plans within reasonable planning horizons. For this reason, a PRINCE2 project has: ... a stage plan for the current stage as a detailed document based on more precise estimates that are achievable within the planning horizon." Ref 7.2.1

"Project managers and team managers always plan using estimates of: Resources - This can be specific materials, equipment, facilities, access, natural resources, or money, as well as the number or amount of each. People - This can be the specific skills required, the level of effort involved, and when and where they will be needed." This is the 'preparing estimates 'step. Ref 7.3.1.3

“The quality practice addresses the quality concepts, guidance, techniques, management products, and responsibilities for the project’s products.” Ref 8.1

The quality register is used "to summarize all quality management activities that are planned or have occurred. The quality register is used by the project manager and project assurance as part of reviewing progress." Ref 8.5

Quality specifications describe "the quality measures that will be applied by those performing quality control and the levels that the finished product must meet." They are stated in product descriptions. Ref 8.1.1

As part of quality planning "product descriptions should include product sustainability requirements captured as quality specifications or acceptance criteria. Product sustainability considers both the environmental impact of the product and the characteristics that will ensure that the product can sustain the realization of its benefits over its expected lifetime." Ref 8.2.1.4

"The user’s quality expectations and acceptance criteria are documented in the project product description produced in the process of starting up a project, which is a primary input to the PRINCE2 planning technique. The project product description is also the primary input to quality planning. "Ref 8.3.1.1.1

“The purpose of the risk practice is to identify, assess and control uncertainties that would affect the project’s objectives, and, as a result, improve the ability of the project to succeed.” Ref 9.1

It is the project initiation documentation: risk management approach that "… includes the specific procedures, techniques, standards, and responsibilities to be applied." In addition, "A risk is measured by a combination of the likelihood of a perceived threat or opportunity occurring and the magnitude of its impact on objectives." Ref 9.5, 9.1

The definition of a risk is "an uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives." Ref 9.1

"A useful way of summarizing the set of risks and their estimations is to plot them onto a risk matrix... This represents a situation at a specific point in time (such as a snapshot of the risk environment) ... The risks above and to the right of the dashed risk tolerance line represent those that the business will not tolerate except, under special circumstances. "Risk exposure is defined as "The degree to which a particular objective is ‘at risk’." Ref 9.2.2, Glossary

The 'identify - define context and objectives' sub-step obtains "information about the project to ensure that there is a common understanding of the specific objectives that are at risk and to formulate an appropriate risk management approach. "Ref 9.3.1.1

“Issues may be raised at any time during the project by any team member or stakeholder.” Therefore, the senior user should raise the issue as soon as it has been identified. Ref 10.1

“The purpose of the issue register is to log all issue reports raised during the project lifecycle, their current status, and date of closure.” And is part of the project log. Ref 10.5

The definition of a request for change is "a proposal for a change to a baseline." Ref 10.2.3

As part of the 'delegating authority for changes 'element of effective guidance, "if there is too much delegation, particularly to too many different roles, there is an increased risk that the overall benefits of the project will be reduced as alignment with the business justification is diluted." Ref 10.2.4

As part of the 'assessing issues' step, "when reviewing issues, the aim is to answer three questions: What is the type of issue (a problem or concern, an event external to the project, a business opportunity, a request for change, or an off specification)? Does this issue affect the project? If so – how? "Therefore, the assessment should consider the impact of an issue or change on the project business case." Ref 10.3.1.2

A key component of project management is controlling the project’s progress, which ensures that the project remains viable against its approved business case. Progress control involves measuring actual progress against the performance targets of benefits, time, cost, quality, scope, sustainability, and risk. This information is used to make decisions such as whether to approve a stage or work package, whether to escalate deviations, or whether to prematurely close the project, and to take actions as required. Progress can be monitored at work package, stage and project level." Ref 11.1

End stage reports are produced by the project manager at the end of each stage "to give a summary of progress to date, the overall project situation, and sufficient information to ask for a project board decision on what to do next with the project." A stage is defined as "the section of a project that the project manager is managing on behalf of the project board at any one time." Ref 11.5, Glossary

The business layer, outside the project team, sets the overall requirements and tolerance levels for the project. "Ref 11.2.1

"The business layer, outside the project team, sets the overall requirements and tolerance levels for the project. "This includes the overall time tolerance for the project. Ref11.2.1

As part of step 1 of the ‘exception management ’technique, "if the issue can be resolved by the project manager within the stage tolerances, the resolution will not require an exception report to be created." Ref 11.3.1.1

As part of step 1 of the ‘exception management ’technique, "if the issue can be resolved by the project manager within the stage tolerances, the resolution will not require an exception report to be created." Ref 11.3.1.1

“The purpose of the process of managing product delivery is to control the link between the project manager and the team manager. This is achieved by agreeing the requirements for acceptance, execution, reporting, and delivery of specialist products. The role of the team manager is to coordinate an area of work that will deliver one or more of the specialist products that form the project product.” Ref 17.1

“The purpose of the process of closing a project is to provide a fixed point at which acceptance of the project product is confirmed, and to recognize that objectives or the approved changes to the objectives as established in the project initiation documentation have been achieved or where there is a cause for a premature close, that the project is closed in an orderly way.” Ref 19.1

1.“The objectives of the starting up a project process are toensure: … sufficient information is available to define andconfirm the scope of the project (in the form of a project brief).”Ref 13.2
4.“The objectives of the starting up a project process are to ensure: … alternative approaches have been evaluated and the chosen project approach agreed.” Ref 13.2

1.“The objectives of the directing a project process are to ensure: … there is authority to close the project.” Ref 14.2
2.“The objectives of the directing a project process are to ensure: … plans for realizing the post-project benefits are managed and reviewed.” Ref 14.2

1.“The objectives of the controlling a stage process are to ensure that: … risks and issues are controlled.” Ref 16.2
4.“The objectives of the controlling a stage process are to ensure that: … the business case is kept under review.” Ref16.2

“An early identifier of potential failure is the project manager’s forecast that any of the project or stage tolerances are likely to be exceeded. In such cases, it is important to have a mechanism for corrective action to bring the project back into the right direction. … The process of managing a stage boundary provides a means by which an exception procedure can be implemented.” Ref 18.3

"Normally the process of controlling a stage is used first after the project board authorizes the project, but it can be used during the initiation stage, especially for large or complex projects." Ref 16.3

“One of the defining features of a project is that it is finite; it has a start and an end. If the project loses this distinction, it loses some of its advantages over purely operational management approaches.” In addition, "When the desired change has been implemented, business as usual resumes (in its new form), and the need for the project is removed. As projects are temporary, they should therefore have a defined start and a defined end." Ref 19.3, 1.3.1