17
Controlling a stage
This chapter covers:
•authorizing, receiving and reviewing work packages
•reviewing the stage status
•using reports to manage progress
•managing risks and issues that may impact the plan
•guidelines for tailoring products and roles
17 Controlling a stage
The purpose of the controlling a stage process is to assign work to be done, monitor such work, deal with issues, report progress to the project board, and take corrective actions to ensure that the management stage remains within tolerance.
The objective of the controlling a stage process is to ensure that:
•attention is focused on delivery of the management stage’s products. Any movement away from the direction and products agreed at the start of the management stage is monitored to avoid uncontrolled change and loss of focus
•risks and issues are kept under control
•the business case is kept under review
•the agreed products for the management stage are delivered to stated quality standards, within cost, effort and time agreed, and ultimately in support of the achievement of the defined benefits
•the project management team is focused on delivery within the tolerances laid down.
Figure 17.1 provides an overview of controlling a stage.
The controlling a stage process describes the work of the project manager in handling the day-to-day management of the management stage. This process will be used for each delivery stage of a project. Towards the end of each management stage, except the final one, the activities within the managing a stage boundary process (see Chapter 19) will occur.
The controlling a stage process is normally first used after the project board authorizes the project, but it may also be used during the initiation stage, especially for large or complex projects.
Work packages are used to define and control the work to be done, and also to set tolerances for the team manager(s). If the project manager is fulfilling the team manager role, work packages should still be used to define and control the work of the individual team members being assigned work. When this is the case, references to the team manager throughout the controlling a stage process should be regarded as references to the individual team member being assigned work.
Central to the ultimate success of the project is the day-to-day control of the work that is being conducted. Throughout a management stage, this will consist of a cycle of:
•authorizing work to be done
•monitoring progress information about that work, including signing off completed work packages
•reviewing the situation (including that for product quality) and triggering new work packages
•reporting highlights
•watching for, assessing and dealing with issues and risks
•taking any necessary corrective action.
Towards the end of the last management stage, the closing a project process (see Chapter 20) will be invoked.
Controlling a stage activities are project manager oriented and comprise:
•Work packages:
•authorize a work package
•review work package status
•receive completed work packages.
•Monitoring and reporting:
•review the management stage status
•report highlights.
•Issues and risks:
•capture and assess issues and risks
•escalate issues and risks
•take corrective action.
17.4.1 Authorize a work package
If the people who are working on the project were to start activities whenever they thought fit, it would be chaotic. There must be a level of autonomy within the project team(s), but there will be wider issues involved of which they cannot be expected to be aware. It is therefore important that work only commences and continues with the consent of the project manager. The vehicle for this is the production, execution and delivery of a work package.
A work package may include extracts from, or simply make cross-reference to elements of, the project plan, stage plan or PID.
A work package should cover the work to create one or more products. If a product requires more than one work package to create it, then it should be broken down into further products with their supporting product descriptions.
The triggers for the project manager to authorize a work package include:
•stage authorization: the project board gives authority to execute a stage plan
•exception plan approved: the project board gives authority to execute an exception plan
•new work package required: an output from reviewing the management stage status (see section 17.4.4)
•corrective action: in response to an issue or risk.
This activity is used to authorize new work packages or to authorize amendments to existing ones.
Figure 17.2 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Examine the stage plan for the current management stage to understand the:
•products to be produced
•cost and effort that the work is expected to consume
•tolerances available.
•Examine the PID to understand:
•the project controls required (e.g. progress reporting arrangements)
•the quality standards required, as defined in the quality management approach
•if any products are to be handed over, how this will be done (as defined in the change control approach).
•Define each work package to be authorized (or amended):
•obtain the relevant product descriptions for inclusion in the work package
•if an agile approach is being used, prioritize the products and features to be delivered
•define the techniques, processes and procedures to be used
•define the development interfaces to be maintained
•define the operational and maintenance interfaces to be maintained
•define the change control requirements
•define the joint agreements on effort, cost, start and end dates, key milestones and tolerances
•define any constraints that may apply
•define the reporting, problem handling and escalation arrangements
•define the approval method
•provide relevant references (e.g. stage plan, product descriptions).
•Review the work package with the team manager, ensure that they have accepted it, and authorize them to begin work (see Chapter 18).
•Review the team manager’s team plan (or the milestone extract from it if the commercial environment means it is inappropriate for the project manager to see its contents) and update the stage plan to reflect the timing of the work package(s) authorized.
•Update any configuration item records, if used, to reflect the content of the work package(s) authorized.
•Update the quality register for planned quality management activities. Consult with project assurance that the identified and selected quality reviewers are acceptable.
•If necessary, update the risk register in accordance with the risk management approach.
•If necessary, update the issue register in accordance with the change control approach.
Table 17.1 shows the responsibilities for this activity.
Table 17.1 Authorize a work package: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
17.4.2 Review work package status
This activity provides the means for a regular assessment of the status of the work package(s). The frequency and formality of this activity will usually be aligned with the frequency of reporting defined in the work package(s) and supported by the stage plan for the current management stage.
Figure 17.3 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions for each work package in progress:
•Collect and review progress information from the checkpoint report for the work package being executed:
•assess the estimated time and effort to complete any unfinished work (including that not yet started)
•review the team plan with the team manager (or the milestone extract from it if the commercial environment means it is inappropriate for the project manager to see its contents) to ascertain whether work will be completed on time and to budget
•review entries in the quality register to understand the current status of quality management activities
•if used, confirm that the configuration item record for each product in the work package matches its status.
•If necessary, update the risk register and issue register.
•Update the stage plan for the current management stage with actuals to date, forecasts and adjustments.
Table 17.2 shows the responsibilities for this activity.
Table 17.2 Review work package status: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
17.4.3 Receive completed work packages
When work has been allocated to individuals or teams, there should be a matching confirmation that the work has been completed and approved.
When approved, any subsequent changes to the product(s) must pass through change control (see Chapter 11). This should be an automatic part of any change control method being used.
Figure 17.4 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Ensure that the team manager has completed the work defined by the work package or, if an agile approach is being used, has delivered the features agreed for the timebox.
•Check that the quality register entries relating to the product(s) are complete.
•Ensure that each product in the work package has gained its requisite approval (as defined in the quality responsibilities in its product description).
•If used, confirm that the configuration item record for each approved product has been updated.
•Update the stage plan to show the work package as completed.
Table 17.3 shows the responsibilities for this activity.
Table 17.3 Receive completed work packages: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
17.4.4 Review the management stage status
If the project is not checked on a timely basis, there is a danger that it will get out of control. There needs to be a balance between planning ahead and reacting to events.
In order to make informed decisions and exercise rational control, it is necessary to compare what has actually happened with what was expected to happen and what might happen next (including any issues and risks). It is therefore essential to have a steady flow of information that provides an overall view of progress and simple, robust monitoring systems to supply that information.
The objective of this activity, therefore, is to maintain an accurate and current picture of progress on the work being carried out and the status of resources.
This activity occurs at a frequency defined in the stage plan, may be triggered by project board advice, or forms part of the analysis of new issues and risks.
Figure 17.5 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review progress for the management stage:
•review checkpoint reports for the period
•review the current stage plan forecast and actuals
•request a product status account from project support to identify any variation between planned progress, reported progress and actual progress
•check for any quality issues shown in the quality register
•check the risk register for any new or revised risks and assess their impact on the business case, stage plan or project plan
•check the issue register to see whether anything has happened within the project or externally that will impact on the business case, stage plan or project plan
•check the status of any corrective actions
•assess the utilization of resources in the period under review and their availability for the remainder of the management stage (or project). Check for any variation in the expected future resource availability
•check the benefits management approach to see whether any benefits management actions are due, and execute them as necessary.
•Based on the above analysis, decide whether any actions are required. For example, whether to:
•authorize a work package (section 17.4.1)
•report highlights (section 17.4.5) in accordance with the communication management approach
•capture and assess issues and risks (section 17.4.6)
•escalate issues and risks (section 17.4.7) if tolerances are threatened
•take corrective action (section 17.4.8)
•seek project board advice (and if necessary provide the project board with the issue report)
•log any lessons that have been identified
•continue as planned.
•Revise the risk register and issue register as necessary.
•Update the stage plan if the aggregated assessment changes any forecasts.
•If ownership of any of the products is to be transferred to the customer as part of a phased handover:
•request a product status account for what is being handed over
•ensure that the:
–products have been approved by those specified in its product description
–products meet all the quality criteria, or are covered by approved concessions
–operation and maintenance organizations are ready to take responsibility for the products
•hand over the products (see Chapter 20). Note that there may be multiple handovers throughout the project lifecycle.
•Consider whether to review lessons now or wait until either a later review of management stage status or when approaching a management stage end.
•If the end of the current management stage is approaching (as indicated by, for example, the stage plan, the contents of the quality register, a milestone etc.), prepare for the next management stage (see Chapter 19).
•If the end of the final management stage is approaching, prepare to close the project (see Chapter 20).
Table 17.4 shows the responsibilities for this activity.
Table 17.4 Review the management stage status: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The project manager must provide the project board with summary information about the status of the management stage and project, and distribute other information to stakeholders at a frequency documented in the communication management approach (as defined by the project board). For more details on progress controls, see Chapter 12.
Figure 17.6 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Assemble the information from the checkpoint reports, risk register, issue register, quality register, lessons log, product status account and any significant revisions to the stage plan for the current reporting period (the information is gained from the review of the management stage status; see section 17.4.4).
•Assemble a list of corrective actions (as noted in the daily log and/or recorded in the issue register) undertaken during the reporting period. This will, for example, assure the project board that the project manager is acting within the agreed tolerances (the information is gained from taking corrective action; see section 17.4.8).
•Review the highlight report for the previous reporting period.
•Produce the highlight report for the current reporting period.
•Distribute the highlight report to the project board and any other recipients identified in the communication management approach.
Table 17.5 shows the responsibilities for this activity.
Table 17.5 Report highlights: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
17.4.6 Capture and assess issues and risks
In the course of managing the project, various issues will occur and risks may be identified. They will arrive in an ad hoc manner and will need to be captured in a consistent and reliable way. Any member of corporate, programme management or the customer, the project or other stakeholders may raise an issue or risk.
Before making a decision on a course of action, each issue or risk should be registered and then assessed for its impact. For more details on risk management, see Chapter 10. For more details on issue and change control procedures, see Chapter 11.
Figure 17.7 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•If an issue can be dealt with by the project manager informally, then this should be done, and a note made in the daily log (see section 11.4 for more information).
•For issues that need to be managed formally (see section 11.4 for more information):
•check the requirements of the issue management and change control procedure in the change control approach
•manage the issue in accordance with the change control approach
•report the status of the issue in accordance with the change control approach and check the communication management approach to see whether there are any external parties that need to be informed of the issue.
•For risks (see Chapter 10 for more information):
•check the requirements of the risk management procedure in the risk management approach
•manage the risk in accordance with the risk management approach
•report the status of the risk in accordance with the risk management approach and check the communication management approach to see whether there are any external parties that need to be informed of the risk.
•If it is necessary to take corrective action, seek advice from the project board or escalate an issue or risk, then review the management stage status first so that a full picture can be considered (see section 17.4.4).
Table 17.6 shows the responsibilities for this activity.
Table 17.6 Capture and assess issues and risks: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
17.4.7 Escalate issues and risks
A management stage should not exceed the tolerances agreed with the project board. The project manager can only take corrective action or maintain the status quo as long as the management stage (or project) is forecast to be completed within the tolerances set by the project board. This activity applies where any corrective action within the project manager’s control would not save the management stage (or project) from going beyond the tolerances agreed. This applies to all types of issue and risk (or aggregations of them) that cannot be resolved within the tolerances set by the project board.
As it may take some time to gather the information to create an exception report, it is recommended that the project board be alerted as early as possible. Therefore, the project manager may wish to execute this activity in two steps: an early notification to the project board of the forecast exception situation so that the board is prepared, followed by supporting information in the form of an exception report.
The project manager should execute any decision by the project board in response to the escalation. Escalating issues and risks is good practice and should not be seen as failure. The earlier that issues are escalated, the more time is available to implement any corrective actions.
For more details on management of risk, see Chapter 10. For more details on issue and change control, see Chapter 11. For more details on exception management, see Chapter 12.
Figure 17.8 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Examine the stage plan to define the extent of the deviation and the unfinished products, and to extrapolate what would happen if the deviation were allowed to continue.
•Examine the project plan for the project status and overall effect of any deviation (using the current baseline of the PID).
•Determine the options for recovery and assess them against the business case.
•Assess the impact of the options for recovery against the stage plan for the current management stage. Consideration should be given to the availability of individuals or groups with the skills or experience to assess the impact.
•Put the situation, options and the recommendation for a course of action to the project board in an exception report. The project board will then decide on an appropriate course of action (which may support or otherwise the project manager’s recommendation). This may include:
•requesting more information or more time to consider its response
•approving, deferring or rejecting a request for change
•granting a concession for an off-specification, or deferring or rejecting it
•increasing the tolerances that are forecast to be breached
•instructing the project manager to produce an exception plan, stating what will be acceptable (see section 19.4.5)
•instructing the project manager to close the project prematurely (see Chapter 20).
Table 17.7 shows the responsibilities for this activity.
Table 17.7 Escalate issues and risks: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
Changes and adjustments to the project need to be made in a considered and rational way, even when they appear to be easily manageable and within tolerances.
In taking corrective action, the objective is to select and, within the limits of the management stage and project tolerances, implement actions that will resolve deviations from the plan. Corrective action is triggered during the review of the management stage status (section 17.4.4) and typically involves dealing with advice and guidance received from the project board, and with issues raised by team managers.
For more details on planning, see Chapter 9. For more details on issue and change control, see Chapter 11.
Figure 17.9 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Collect any relevant information about the deviation.
•Identify the potential ways of dealing with the deviation and select the most appropriate option.
•Trigger corrective action via authorizing a work package (see section 17.4.1).
•If used, update the configuration item records of the affected products.
•Update the issue report (if necessary) to show the status of the corrective action.
•Update the issue register with any changes resulting from the corrective action (or if being handled informally, update the daily log with the details and status of the corrective action).
•Update the risk register with any changes resulting from the corrective action.
•Update the stage plan for the current management stage.
Table 17.8 shows the responsibilities for this activity.
Table 17.8 Take corrective action: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
The work packages are fundamentally important to this process as they relate to the PRINCE2 principle to focus on products.
17.5.2 Tailoring products in controlling a stage
Table 17.9 provides tailoring guidelines for management products in controlling a stage.
Tip
As it is within this process that much of the tailoring is used, the project manager should continually monitor the effectiveness of the procedures and controls. Where necessary, the project manager takes corrective action, which might entail further tailoring and an update to the PID. For example, it may be found that the summary risk profile matrix categorizes all risks as ‘high’ (when they are clearly not) and needs to be adjusted to give a meaningful spread.
Table 17.9 Guidelines for tailoring products in controlling a stage
Management product |
Tailoring guidelines |
Work package |
Work packages can take many forms as specialist disciplines often have their own practices for defining their specialist deliverables. They are also likely to differ if the work is done internally or contracted to a supplier. The project manager should use the work package outline as a checklist to ensure that the relevant content is present. |
Highlight report |
The frequency of highlight reporting may change to suit the risk profile and output being created. This is documented in the communication management approach in the PID. Additional information, such as KPIs, may be added or referenced if it provides clarity. Highlight reports may be in the form of wall charts or Kanban boards. |
Issue report |
An issue report is simply a view of the issue register with additional information covering an impact analysis, recommendation and decision. If this additional information is added to the issue register, there is no need for a separate, formally documented report. |
Exception report |
As the recipients of the report are the project board members, this report may be in any format acceptable to them as long as it includes the information the project board requires. |
17.5.3 Tailoring roles in controlling a stage
The project manager is responsible for the creation of all new management products in this process, but may delegate this to others, while retaining accountability. For example, PRINCE2 shows the project manager as responsible for creating work packages. However, in practice they may not have the requisite skills to define specialist products and their role is rather to see that they are defined and reviewed rigorously.
17.5.4.1 Controlling a stage on a simple project
For a simple project, when the project manager also acts as the team manager, the project manager may choose to use work packages as a control for individual team members.
The project manager is likely to undertake the project support role personally.
17.5.4.2 Controlling a stage when using an agile approach
When controlling a stage that is using an agile approach, the project manager should empower the teams to deliver in the best way possible. This means being collaborative with work assignment, based around the amount of requirements to be delivered (e.g. in the form of features), and making full use of the most effective visual communication channels. Further to this, the use of regular reviews and retrospectives along with setting the appropriate tolerances (based primarily around scope and quality criteria) creates an environment where creativity and responding to change exist in order to best address the customer’s needs.
Team members typically plan their work according to the order decided by the customer (this role is often referred to as a product owner), who is in the delivery team. As a result, work is typically not assigned to specific team members in advance. Work packages are structured flexibly (e.g. through the use of tolerances) to enable teams to self-organize, and their sign-off may be informal. Reviews and demos at the end of a sprint or a release provide transparent and regular feedback to the customer as a means of validating that the acceptance criteria in the product description(s) have been met. A work package may contain several timeboxes (e.g. in the form of sprints) and, although each one will deliver something, they may not necessarily deliver something into operational use.
When using an agile approach, teams track progress during a short meeting called a daily stand-up. The project manager or team managers may be invited to attend/assist stand-up meetings if appropriate, and/or facilitate them. Reporting of progress is typically done via wall charts or information radiators, from which information can be pulled at any time by any project stakeholder.
Forecasting in general is more likely to be in an empirical style (based on evidence), with progress usually shown as a burn chart rather than a Gantt chart. The project manager should focus on flexing the scope and the quality criteria of the defined products and ensuring that those variables stay within agreed tolerances.
The daily stand-up provides the delivery team with the opportunity to identify issues and risks. This approach ensures they are uncovered and escalated quickly to ensure that goals are not compromised. Sprint and release retrospectives also provide an opportunity to improve the underlying processes that the team is using.
17.5.4.3 Controlling a stage from a supplier perspective
For an external supplier, a customer’s work package may take the form of a legally binding contract. However, the supplier may decompose the contracted work packages into smaller work packages to manage its part of the work.
The project manager should ensure that they have sufficient information from the supplier to control the work. This may require specific obligations on the supplier to be included in the contract.
17.5.4.4 Controlling a stage of a project within a programme or portfolio
Consider how the project’s logs and registers should be maintained and how escalation to programme or portfolio level is to be done in practical terms. For example, there may be a single risk register system (administered by the programme or portfolio and including both the programme- or portfolio-level risks and the risks for each project), or each project could maintain its own risk register. If the latter is chosen, the project’s risk management approach should define how programme- or portfolio-level risks that are identified and captured by the project are escalated to the programme or portfolio risk register. Likewise, the programme’s or portfolio’s risk management approach should define mechanisms for project risks that are identified and captured at the programme or portfolio level to be delegated to the project risk register.