In the PRINCE2 7 framework, within the 'Controlling a Stage' process, the activity 'Authorize a Work Package' represents the fundamental delegation mechanism where the Project Manager assigns specific work to a Team Manager. This activity bridges the gap between the project's management layer and the delivery layer, ensuring that no work commences without explicit authorization and a clear understanding of requirements.

The process begins when the Project Manager defines the Work Package, which includes Product Descriptions, techniques, quality criteria, and specific tolerances for time and cost. Crucially, this is not a one-way instruction but a collaborative negotiation. The Team Manager must review the requirements to assess feasibility against their own capacity and skills. They typically formulate a Team Plan to demonstrate how the work will be executed within the constraints provided.

During this interaction, both parties agree on reporting frequencies (Checkpoints), how issues and risks will be escalated, and the specific approval method for the completed products. This step is vital for managing the interface between the project and the supplier or team, particularly when third-party suppliers are involved.

Once the Project Manager is satisfied that the Team Plan is viable and that the Work Package is understood, they formally authorize the work. This triggers the Team Manager to proceed into the 'Managing Product Delivery' process. By strictly adhering to this activity, PRINCE2 prevents scope creep and maintains the 'manage by exception' principle, as the Team Manager is given autonomy to deliver within the agreed tolerances, reporting back only via Checkpoint Reports or if tolerances are forecast to be exceeded. Effectively, it converts the Stage Plan into tangible action while maintaining governance and control.

In the context of the PRINCE2 7 'Controlling a Stage' process, the activity 'Review Work Package Status' serves as the vital connection between the Project Manager and the delivery teams. Its primary purpose is to allow the Project Manager to monitor progress and maintain control over the stage without interfering in the daily technical work, aligning with the principle of 'manage by exception.'

This activity is cyclical and usually triggered by the receipt of a Checkpoint Report from the Team Manager (or the team member responsible). Upon receiving this report, the Project Manager analyzes the progress of the specialist products against the agreed tolerances defined in the Work Package. A critical aspect of this review is assessing the estimated time and effort required to complete the remaining work, rather than merely recording resources already consumed. This ensures accurate forecasting regarding stage completion.

The Project Manager also verifies the status of quality activities, ensuring that products are not just 'done' but meet the specified quality criteria. Additionally, the review involves checking the Configuration Item Records to confirm that the administrative status of products matches reality. Risks and issues raised by the team are assessed to determine their impact on the Stage Plan and the Business Case.

Ultimately, the data derived from this activity—specifically regarding schedule, cost, and quality—is used to update the Stage Plan. If the review reveals that the Work Package is forecast to exceed its tolerances, the Project Manager must analyze the deviation; if the stage tolerances are threatened, this will escalate to the 'Report Highlights' or 'Escalate Issues and Risks' activities. Thus, reviewing Work Package status is essential for maintaining the validity of the plan and ensuring the project remains viable.

In the context of the PRINCE2 7 'Controlling a Stage' process, the activity 'Receive Completed Work Packages' acts as the formal checkpoint where the Project Manager reassumes control of products from the Team Manager. This activity ensures that the handshake between project management and product delivery is governed by quality and verification rather than assumptions.

The process is triggered when the Team Manager notifies the Project Manager that the work defined in a Work Package is finished. However, the Project Manager does not simply accept this notification at face value. Instead, they must perform rigorous checks to confirm the work is truly complete and fit for purpose.

The primary focus is on the **Quality Register**. The Project Manager must verify that all quality management activities—such as testing, inspections, or reviews—specified in the Work Package have been executed. They must confirm that the products have been approved by the designated authorities and that the quality records are complete. In PRINCE2, a product is effectively non-existent until it passes its quality criteria.

Once quality is verified, administrative housekeeping is essential. The **Configuration Item Records** are updated to change the status of the products to 'baselined,' ensuring version control is maintained. Additionally, the **Stage Plan** is updated with the actual progress and completion dates. This updated data is vital for the subsequent activity, 'Review the Stage Status,' allowing the Project Manager to determine if the stage is proceeding within agreed tolerances.

Ultimately, this activity prevents '99% complete' syndrome. By enforcing strict acceptance criteria, the Project Manager ensures that the project only progresses based on verified, quality-assured deliverables.

In the context of the PRINCE2 7 Controlling a Stage process, the 'Review stage status' activity acts as the Project Manager's continuous pulse-check of the project's health. It is not a singular event but a recurring cycle of monitoring and assessment designed to ensure the stage remains within agreed tolerances for time, cost, quality, scope, sustainability, benefits, and risk.

The primary objective is to maintain an accurate, up-to-date picture of progress. To achieve this, the Project Manager gathers data from various sources, predominantly Checkpoint Reports submitted by Team Managers regarding Work Package progress. The Project Manager also reviews the Quality Register to verify product approvals, assesses the Risk Register for changing threats, and consults the Issue Register to track open concerns.

Upon gathering this data, the Project Manager updates the Stage Plan with actuals. Crucially, this activity moves beyond recording history; it focuses heavily on forecasting. The Project Manager must calculate whether the remaining work can be completed within the stage tolerances. If a deviation beyond tolerance is forecast, it triggers the 'Escalate issues and risks' activity. Furthermore, PRINCE2 7 emphasizes the human aspect here; the Project Manager evaluates team dynamics and relationships to ensure continued productivity.

Ultimately, 'Review stage status' provides the raw analysis required for the 'Report highlights' activity. It ensures that any communication sent to the Project Board via Highlight Reports is based on evidence and realistic forecasts, enabling effective Management by Exception.

In the PRINCE2 7 'Controlling a Stage' process, the activity 'Report highlights' describes the Project Manager's duty to provide the Project Board with regular updates via the Highlight Report. This is a 'time-driven' control, occurring at frequencies agreed upon in the Communication Management Approach (e.g., weekly or monthly), distinguishing it from 'event-driven' controls like Exception Reports.

The primary purpose of this activity is to support the principle of 'manage by exception.' It ensures the Project Board is kept informed of the stage's progress without requiring constant meetings or micromanagement. As long as the project remains within agreed tolerances, the Highlight Report serves as the 'heartbeat' of the project, assuring the Board that the stage is under control.

To construct the report, the Project Manager gathers data from Checkpoint Reports (submitted by Team Managers), updates the Stage Plan with actual progress, and reviews the issue and risk registers. The resulting Highlight Report typically includes:

1. **Status Summary:** A high-level indication (often Red/Amber/Green) of the stage's health.
2. **Work Performed:** Details on products completed and Work Packages executed during the reporting period.
3. **Budget and Schedule:** A comparison of actual time and cost against the plan to verify that stage tolerances are intact.
4. **Risks and Issues:** A summary of key risks and issues managed during the period, along with any corrective actions taken.
5. **Next Period Forecast:** An outline of the work planned for the upcoming interval.

If, during the preparation of this report, the Project Manager forecasts that stage tolerances will be exceeded, the process shifts to 'Escalate issues and risks,' and an Exception Report is generated instead.

In PRINCE2 7, the 'Capture and examine issues and risks' activity within the Controlling a Stage process is the primary mechanism for managing deviations and changes. An issue is defined as any relevant event that has happened, was not planned, and requires management action. They are categorized as Requests for Change, Off-specifications, or Problems/Concerns.

The process involves two distinct steps:

1. **Capture**: The Project Manager must formally record the issue. Minor issues may go into the Daily Log, while formal issues are recorded in the Issue Register. An Issue Report is created to describe the issue clearly. This step ensures that nothing is lost and an audit trail is maintained.

2. **Examine**: The Project Manager acts to understand the issue's impact. This involves assessing how the issue affects the six performance targets of the current Stage Plan and the overall Project Plan: time, cost, quality, scope, benefits, and risk. Crucially, the Project Manager checks the impact against the Business Case and sustainability targets.

During examination, the Project Manager prioritizes the issue (often using MoSCoW) and assesses its severity. The critical decision point is checking against **tolerances**. If the proposed solution to the issue can be executed within the agreed Stage Tolerances, the Project Manager can take corrective action. However, if the issue is forecasted to breach stage tolerances, it becomes an 'Exception.' In this case, the Project Manager cannot decide unilaterally; they must escalate to the Project Board via an Exception Report to seek direction.

In the context of the PRINCE2 7 'Controlling a Stage' process, the activity 'Escalate issues and risks' is the definitive application of the principle 'manage by exception.' This activity is triggered when the Project Manager forecasts that any of the agreed stage tolerances (time, cost, quality, scope, benefits, or sustainability) are likely to be exceeded.

The process functions as a safety valve for project governance. When an issue arises or a risk materializes that the Project Manager cannot resolve within their delegated authority, they must not exceed their limits. Instead, they must formally alert the Project Board. The Project Manager first analyzes the situation to assess the impact on the stage and project objectives.

The primary output of this activity is the **Exception Report**. This report is critical; it provides the Project Board with a description of the exception, the cause, the consequences for the Business Case, and the available options for the way forward, complete with a recommendation. This ensures the Project Board has sufficient data to make an informed decision.

Once the Exception Report is submitted, the issue effectively moves up to the 'Directing a Project' process. While the Project Manager awaits a decision, they continue to monitor the situation but do not implement significant corrective actions that would violate tolerances. The Project Board will eventually respond, typically by requesting an Exception Plan to replace the current Stage Plan, or by providing other specific directions. This mechanism ensures that senior management remains in control of significant deviations while the Project Manager handles day-to-day delivery.

In the context of the PRINCE2 7 'Controlling a Stage' process, the activity 'Take corrective action' represents the practical application of the Project Manager's authority to keep the stage within agreed limits. This activity is triggered when monitoring reveals a deviation from the Stage Plan—such as a delay reported in a Checkpoint Report or a newly identified issue—that requires intervention but is currently forecast to remain within stage tolerances.

The Project Manager analyzes the deviation to determine the most effective response. The goal is to solve the problem at the stage level without burdening the Project Board, adhering to the principle of 'Management by Exception.' Corrective actions might include rescheduling tasks, adjusting resource allocations within the team, or addressing a small scope change if a change budget is available and authorized.

If the Project Manager determines that the corrective action will resolve the issue while keeping the stage within its time, cost, quality, scope, benefit, risk, and sustainability tolerances, they proceed to update the Stage Plan and Issue Register and issue new Work Packages if necessary. This autonomy is crucial for efficient project flow.

However, this activity is strictly bounded by tolerance. If the analysis shows that the necessary corrective action would cause a breach of stage tolerances, the Project Manager cannot simply 'take action.' Instead, they must immediately escalate the situation by raising an Exception Report for the Project Board to consider. Thus, 'Take corrective action' is the mechanism for solving day-to-day problems, ensuring the stage remains viable and aligned with the business case.