19
Managing a stage boundary
This chapter covers:
•reviewing the current stage
•planning for the next stage
•updating the project plan and business case
•reporting the stage end
•producing an exception report and exception plan
•guidelines for tailoring products and roles
19 Managing a stage boundary
The purpose of the managing a stage boundary process is to enable the project manager to provide the project board with sufficient information to be able to:
•review the success of the current management stage
•approve the next stage plan
•review the updated project plan
•confirm continued business justification and acceptability of the risks.
Therefore, the process should be executed at, or close to, the end of each management stage.
Projects do not always go to plan and in response to an exception report (if the management stage or project is forecast to exceed its tolerances) the project board may request that the current management stage (and possibly the project) is replanned. The output from replanning is an exception plan which is submitted for project board approval in the same way that a stage plan is submitted for approval.
The objective of the managing a stage boundary process is to:
•assure the project board that all products in the stage plan for the current management stage have been completed and approved
•prepare the stage plan for the next management stage
•review and, if necessary, update the PID; in particular the business case, project plan, project approaches, project management team structure and role descriptions
•provide the information needed for the project board to assess the continuing viability of the project
•record any information or lessons that can help later management stages of this project and/or other projects
•request authorization to start the next management stage.
For exceptions, the objectives of the managing a stage boundary process are to:
•review and, if necessary, update the PID; in particular the customer’s quality expectations, project approaches and controls, and role descriptions
•provide the information needed for the project board to assess the continuing viability of the project
•prepare an exception plan as directed by the project board
•seek approval to replace the project plan or stage plan for the current management stage with the exception plan.
Managing a stage boundary is not used towards the end of the final management stage unless there is a need to create an exception plan. This is because the activities to review the performance of the whole project, as part of the closing a project process, include reviewing the performance of the final management stage.
Figure 19.1 provides an overview of managing a stage boundary.
The managing a stage boundary process is predicated on dividing the project into management stages (see Chapter 13).
A project, whether large or small, needs to ensure that the products it creates will deliver the benefits being sought, either in their own right or as part of a larger programme. The continuing correct focus of the project should be confirmed at the end of each management stage. If necessary, the project can be redirected or stopped to avoid wasting time and money.
It is also important to recognize that projects can go wrong or can be affected by external factors that invalidate the business justification. An early identifier of potential failure is the project manager’s forecast that any of the project or management stage tolerances are likely to be exceeded. In such cases it is important to have a mechanism for corrective action in order to bring the project back into the right direction.
A positive decision not to proceed is not failure. However, providing insufficient information that prevents the project board from making an informed decision is itself a failure as it may lead to a wrong decision.
The managing a stage boundary process provides a means by which an exception process can be implemented.
The activities within the managing a stage boundary process are project manager oriented and are to:
•plan the next management stage
•update the project plan
•update the business case
•report management stage end
•produce an exception plan.
19.4.1 Plan the next management stage
The stage plan for the next management stage is produced near the end of the current management stage. Closure activities should be planned as part of the stage plan for the final management stage.
Planning is not an activity undertaken in isolation. The project manager will need to consult with the project board, project assurance, team managers and possibly other stakeholders in order to create a viable plan. The more people involved in planning, the more robust the plan will be (as long as the right people are involved). See Chapter 9 for more details on planning.
Figure 19.2 shows the inputs to, and outputs from, this activity.
Tip
It is good practice to produce a team plan in parallel with planning the next management stage. It should be reviewed and, if necessary, updated as part of the accept a work package activity. This will ensure that the project manager has sufficient information to plan the stage, with an understanding of what is achievable at a team level.
PRINCE2 recommends the following actions:
•Review the components of the PID. It may be necessary to consult with the project board regarding any required changes. The following should be reviewed and, if necessary, updated:
•any change to the customer’s quality expectations, acceptance criteria or project approach
•the relevance and suitability of the approaches and controls
•any change in the project management team or their role descriptions (in particular the situation with regard to external resources or suppliers as these may affect the stage plan).
•Produce the stage plan for the next management stage:
•decide how the plan can best be presented given its audience, and how it will be used
•review the project plan to understand the products required for the next management stage
•examine the quality management approach for the quality standards and procedures required
•if used, create (or update) the product breakdown structure, product descriptions and product flow diagram for the products to be delivered by the next management stage
•review the issue register as it may contain issues marked for assessment at the management stage end or information that affects the next management stage
•review the risk register for any risks that may affect the stage plan for the next management stage, and check the status of risk responses by consulting with the risk owners.
•Create (or update) configuration item records, if used, for products planned to be produced in the next stage.
•Update the issue register and risk register if any new issues or risks have been identified (or if existing ones need to be modified).
•Update the quality register for planned quality management activities. This should include target review and approval dates for the products.
Table 19.1 shows the responsibilities for this activity.
Table 19.1 Plan the next management stage: 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).
19.4.2 Update the project plan
The project board uses the project plan throughout the project to measure progress.
The project plan is updated to incorporate actual progress from the management stage that is finishing, and to include forecast duration and costs from the exception plan or stage plan for the management stage about to begin. Details of any revised costs or end dates are used when updating the business case. See Chapter 9 for more details on planning.
Figure 19.3 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Check that the current stage plan is up to date with actual progress and update it if necessary.
•Revise the project plan to reflect:
•actuals from the current stage plan
•forecasts from the next stage plan, or the impact of the exception plan
•any changes to the project product description
•the implications of any issues or risks
•any new or changed PRINCE2 process-tailoring requirements for the project
•any changed or extra products sanctioned by the project board
•any changes within the PID (e.g. revised project approaches, project controls, project management team structure or role descriptions).
•Update the issue register and risk register if any new issues or risks have been identified (or if existing ones need to be modified).
Table 19.2 shows the responsibilities for this activity.
Table 19.2 Update the project plan: 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).
19.4.3 Update the business case
It is a PRINCE2 principle that projects have continued business justification.
The project board is ordinarily only authorized to continue while the project remains viable (i.e. the benefits will be realized within the time, cost, quality, scope and risk parameters set out in the currently agreed business case).
Projects, however, do not take place in a static environment. The environment external to the project changes, as does the development of the project product. The business case needs to reflect these changes and must be reviewed and amended to keep it relevant to the project. As the executive is responsible for the business case, the project manager should consult with the executive when reviewing and updating the business case in preparation for project board approval. For further details on business justification, see Chapter 6.
Figure 19.4 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Check whether there have been any changes to the risk appetite and risk capacity of the organizations involved and whether risk tolerances need to be redefined. Assess the project’s risks using the risk register to ascertain the aggregated risk exposure for the project and identify the current key risks that affect the business case. This should include an assessment that the aggregated risk exposure remains within risk tolerances.
•Update the benefits management approach with the results from any benefits management actions undertaken during the management stage.
•Examine and review:
•the benefits management approach for the results of any benefits management actions undertaken during the management stage compared with the expected results
•the impact of approved changes as these may affect the projected benefits
•the project risk profile and key risks
•the issue register for any issues that may affect the business case
•the project plan to see whether the final implementation date of the project has changed (to earlier or later), which might affect some or all of the projected benefits
•the project plan to see whether the cost of delivering the project product has changed, which may affect the cost–benefit analysis
•the corporate, programme management or customer environment into which the project product will be delivered, as it may have changed
•whether any benefits reviews are required in the next management stage.
•Revise the business case and, if necessary, the benefits management approach, ready for project board approval.
•Update the risk register and issue register as necessary.
Table 19.3 shows the responsibilities for this activity.
Table 19.3 Update the business case: 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).
19.4.4 Report management stage end
The results of a management stage should be reported back to the project board so that progress is clearly visible to the project management team.
The project manager gives a view on the continuing ability of the project to meet the project plan and business case, and assesses the overall risk situation. This activity should happen as close as possible to the actual end of a management stage.
Figure 19.5 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•For an exception plan:
•depending on the point within the management stage when the exception occurred, it may be appropriate to produce an end stage report for the activities to date. Whether this is required will be advised by the project board in response to the exception report. If an end stage report is required, then follow the guidance for a stage plan below.
•For a stage plan:
•review the status of the updated business case and, in particular, the achievement of any benefits anticipated for the management stage. Confirm that any activities in the benefits management approach for the current management stage have been completed
•review the stage plan to ensure that the objectives of the management stage have been met, and the project plan to ensure that the project objectives are still achievable
•review the team performance for the management stage
•review the product performance for the management stage by reference to the product status account (provided by project support):
–review the quality management activities for the management stage and their results
–ensure that all the products planned to be created within the stage plan for the current management stage are complete and approved, or have been carried forward into the next management stage
–if a phased handover of products (see section 20.4.3) occurred during the management stage, confirm user acceptance and operational and maintenance acceptance of the products transferred to customer ownership. Identify any follow-on action recommendations for the products handed over
•review the issues and risks raised during the stage and any risk response actions taken. Include a summary of the current aggregated risk exposure
•prepare an end stage report for the current management stage.
•If appropriate, review the lessons at this time, particularly for longer projects, where interim reviews of lessons, or the project itself, may benefit corporate, programme management or the customer.
•Seek approval from the project board of the exception plan or stage plan (and, if appropriate, the revised project plan, the revised benefits management approach and the revised business case; see Chapter 15).
•Review the communication management approach to see whether there is a requirement to send copies of the end stage report (and, if appropriate, a lessons report) to external interested parties at this time.
Table 19.4 shows the responsibilities for this activity.
Table 19.4 Report management stage end: 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).
19.4.5 Produce an exception plan
If a management stage or the project is forecast to deviate beyond its agreed tolerances, it no longer has the approval of the project board.
Exception plans are requested by the project board in response to an exception report. Although an exception plan will be produced prior to the planned management stage boundary, its approval by the project board marks a management stage boundary for the revised management stage.
Planning is not an activity undertaken in isolation. The project manager will need to consult with project board members, project assurance, team managers and possibly other stakeholders in order to create a viable plan. The more people involved in planning, the more robust the plan will be. See Chapter 9 for more details on planning.
Figure 19.6 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Update the issue register (and, if necessary, the issue report) to record the project board’s request for an exception plan.
•Review and, if needed, update the PID. It may be necessary to consult with the project board regarding any required changes. The following should be reviewed:
•the customer’s quality expectations: do they remain unchanged?
•the relevance and suitability of the project approaches and controls
•any change in the project management team or their role descriptions (in particular the situation with regard to external resources or suppliers as these may affect the exception plan).
•Produce the exception plan:
•examine the stage plan to identify the products planned to be created during the management stage
•examine the exception report for details (such as recommended actions) that will contribute to the exception plan
•if the exception plan requires new products to be created, then examine the quality management approach for the quality standards and procedures required
•update the product breakdown structure, product descriptions and product flow diagram for the products to be created by the exception plan
•update the quality register for planned quality management activities.
•If used, create (or update) configuration item records for products to be produced by the exception plan.
•Update the issue register and risk register if any new issues or risks have been identified (or if existing ones need to be modified).
•Update the quality register for planned quality management activities. This should include target review and approval dates for the products.
Table 19.5 shows the responsibilities for this activity.
Table 19.5 Produce an exception plan: 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 activities in this process may be combined, split or run concurrently to suit the context, but care should be taken to ensure the integrity of the interfaces with the initiating a project, controlling a stage and directing a project processes.
Although this process is called managing a stage boundary, it also covers the preparation of an exception plan within a stage when tolerances are exceeded. Managing a stage boundary is used when dealing with planned or unplanned activities (such as exceptions).
19.5.2 Tailoring products in managing a stage boundary
Table 19.6 provides tailoring guidelines for management products in managing a stage boundary.
Table 19.6 Guidelines for tailoring products in managing a stage boundary
Management product |
Tailoring guidelines |
Stage plan |
If there are only two management stages (one for initiation and the other for delivery), the stage plan can be included in the project plan. |
Product descriptions |
The project product description and product descriptions are key as they relate to the PRINCE2 focus on products principle. Although PRINCE2 shows the project manager as responsible for creating product descriptions, in practice they may not have the requisite skills to define specialist products. Their role may be to see that the product descriptions are defined and reviewed rigorously enough to enable planning to be undertaken confidently. |
End stage report |
If there is only one delivery stage, then the end of that stage is also the end of the project. In this case an end stage report is not needed as its content would be covered in the end project report within the closing a project process. This product may be split into two parts, one covering progress to date in detail, the other forming the basis of the decision to start the next stage. |
Lessons log |
Lessons from the log or lessons report (if one has been created) may be combined with the end stage report. |
Exception plan |
The plan may include components in any format commensurate with the complexity of the project, with views ranging from a simple list of accountabilities, products, activities and dates to Gantt charts. The plan may be held totally or partially within a planning tool(s). |
19.5.3 Tailoring the roles in managing a stage boundary
The project manager is responsible for the creation of all new management products in this process, but may delegate work to others with the requisite skills, such as project support or a team manager, provided the project manager retains overall responsibility.
19.5.4.1 Managing stage boundaries on a simple project
Some projects may only have two management stages: the initiation stage and one delivery stage. In this case, the scope of managing a stage boundary could be reduced to the report management stage end activity.
Plan the next management stage activity would not be needed if the project plan covered the required detail. The project plan and business case would only have just been produced and would not need updating. Exceptions, however, would still need to follow the managing a stage boundary process.
19.5.4.2 Managing stage boundaries when using an agile approach
Ideally the managing stage boundaries process should not interrupt the natural flow of work using agile, with releases and sprints synchronized within each management stage. This process provides an opportunity to assess the ongoing viability of the project as a whole and to decide what the priorities are for the next management stage. This is to ensure that high-value (most beneficial) work from the product backlog is undertaken in preference to lower-value work. Throughout the stage the frequent delivery of products in an iterative and incremental style will mean that it will be clear how many features have been delivered, their level of quality and value added, and which remain to be covered in later management stages.
19.5.4.3 Managing stage boundaries on a project from a supplier perspective
From a supplier perspective when working on work packages for a customer’s project, the supplier’s input may be to help prepare any plans. From the perspective of the supplier’s project, stage boundaries would normally represent its own decision points within its own project lifecycle and delivery of work packages would need to match the stage boundaries in the customer’s project.
19.5.4.4 Managing stage boundaries on a project within a programme
All the guidance provided above is applicable to a project within a programme, except that any decisions and plans will be made in the context of the programme. If possible, aligning the programme review points with project management stage boundaries may help keep alignment across the programme.