PRINCE2 Foundation Module 3 - Directing a Project Controlling a Stage, and Managing Product Delivery

PRINCE2 Foundation Module 3

Directing a Project Controlling a Stage, and Managing Product Delivery

Learn the Directing a Project process enabling the Project Board to be accountable for the project’s success by making key decisions and exercising overall control. The Controlling a Stage process is to assign work to be done, monitor such work, deal with issues, report progress to the Project Board. The Managing Product Delivery process places formal requirements on accepting, executing and delivering project work.

Directing a Project (DP)

This process is used by the Project Board whose roles represent the business, users and suppliers.

The purpose of the Directing a Project process is to enable the Project Board to be accountable for the project’s success by making key decisions and exercising overall control while delegating day-to-day management of the project to the Project Manager.

One main objective is that management direction and control are provided throughout the project’s life, and that the project remains viable.

Directing a Project starts on completion of the Starting Up a Project process and is triggered by the request to initiate a project. The Project Board should provide unified direction and guidance to the Project Manager.

The process has five trigger activities:

• Authorize initiation.  When the Project Manager has created the management products within the Starting Up a Project process, they will issue a request to initiate the project, and this activity will allow the Project Board to make a decision whether or not to proceed to the Initiation stage.
  
  One of the outputs from this activity is to notify corporate or programme management plus other interested parties, that the project has been authorized.

• Authorize the project.  When the Project Manager has created the management products within the Initiating a Project process, they will issue a request for authorization to deliver the project, and this activity will allow the Project Board to make a decision whether or not to proceed with the rest of the project.

• Authorize a Stage or Exception Plan.  This activity serves two purposes both coming from the Managing a Stage Boundary process, and hence it may be triggered from either one of those. They are, a request from the Project Manager to approve the Next Stage Plan, or, a request from the Project Manager to approve an Exception Plan.

• Give ad hoc direction.  This serves as an open communication channel both to and from the Project Board. It is the destination used for the Highlight, Exception or Issue Reports, or advice request from the Project Manager and to and from corporate/programme management.

• Authorize project closure.  This is the last activity undertaken by the Project Board prior to its own disbandment. It is also used to advise corporate/programme management.

Consider how the Directing a Project supports the seven PRINCE2 Principles:

• Continued business justification. The Executive is responsible for the Business Case, and at each of the five processes (apart from Give ad hoc direction), the Business Case is reviewed and assured that it remains viable
  
• Learn from experience. At each of the five processes (apart from Give ad hoc direction), the Lessons Log is used as an input so that lessons are learned throughout the project. AT the end of the project (although it could be generated at each stage end as well), the Lessons Report is authorized and distributed.

• Defined roles and responsibilities. The Project Board roles and who should fill them along with their responsibilities are agreed and appointed in the starting Up a Project process, and tailored as required throughout the project.

• Manage by stages. The Project Plan shows the stages in terms of timing within the Project Plan and the Project Board both contribute to this as well as authorizing it.
  
  In addition the Project Board authorizes the project one stage at a time to the Project Manager. Each successive stage does not start until the Project Board has approved its Next Stage Plan.

• Manage by exception. Tolerances are set for each stage by the Project Board, and the Executive is accountable to corporate/programme management for ensuring the project falls within their project tolerance. The activity Authorize a Stage or Exception Plan is used when managing exceptions.

• Focus on products. Management products within the PID are created and the PRINCE2 product-based planning technique is used for Project Plan and Stage Plan creation. All of these are approved by the Project Board.

• Tailor to suit the project environment. The Project Approach was designed taking into consideration the entire project environment, and this will be used here as a key input to all management products which are approved by the Project Board. The Project Board is tailored in terms of how their roles are filled or shared.

This process is aimed at the Project Board. The Project Board manages and monitors via reports and controls through a number of decision points.

This process does not cover the day-to-day activities of the Project Manager.

The Project Board are accountable for the project’s success by making all the key decisions, and must have the authority to exercise overall control and commit resources during the project life cycle.

The Project Board manages by exception, monitors via reports, and controls through a number of decision points.

The Directing a Project process runs from the start-up of the project until its closure.

Directing a Project

• You understand the purpose statement and could easily identify any errors contained within it
• You understand that the Project Board is there to manage, and not carry out the work itself, rather their job is to focus on decision-making
• You appreciate this process is mainly about making decisions and how that relates to the five activities within it
• You know the names of the five activities, and why the activity giving Ad-Hoc direction is different. In addition, you understand the typical information and two-way communication use of this activity
• You understand how the activity giving Ad-Hoc direction is used to trigger project premature close
• You fully understand how the Project Board roles fulfil the business, user, and supplier viewpoints
• You understand the Project Board responsibilities contained within each role
• You know the relationship between the Project Board responsibilities, Project Assurance, and a change authority, in particular the use of Project Board or independent individuals to fill those roles
• You are familiar with the Project Board responsibilities at the end of a stage or when holding an exception assessment

Directing a Project process

Foundation Exam learning outcomes

• You understand the purpose statement and could easily identify any errors contained within it
• You understand that the Project Board is there to manage, and not carry out the work itself, rather their job is to focus on decision-making
• You appreciate this process is mainly about making decisions and how that relates to the five activities within it
• You know the names of the five activities, and why the activity giving Ad-Hoc direction is different.  In addition, you understand the typical information and two-way communication use of this activity
• You understand how the activity giving Ad-Hoc direction is used to trigger project premature close
• You fully understand how the Project Board roles fulfil the business, user, and supplier viewpoints
• You understand the Project Board responsibilities contained within each role
• You know the relationship between the Project Board responsibilities, Project Assurance, and a change authority, specifically, the use of Project Board or independent individuals to fill those roles
• You are familiar with the Project Board responsibilities at the end of a stage or when holding an exception assessment

Controlling a Stage (CS)

The Project Manager is given responsibility for day-to-day management of the project, one stage at a time.

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 action to ensure that the stage remains within tolerance.

As part of an End Stage Assessment (or an Exception Assessment), the Project Board will approve the Next Stage Plan (or Exception Plan), ask for a new draft, or possibly prematurely close the project. They will also advise the Project Manager how often they want to receive Highlight Reports in the next stage, and they will set Stage Tolerance so that “Management By Exception” can operate.

Controlling a Stage is triggered when:

1. A new stage is authorized by the Project Board

1. An Exception Plan is approved

• When the Project Board gives advice during a stage

1. If a new issue is raised

• When the Team Manager issues a Checkpoint Report

• When a Work Package is completed

The Controlling a Stage process is focused on delivery of the stage’s products to stated standards, keep risks under control, the Business Case under review, deliver within the stage cost, work effort and duration, and within the agreed tolerances.

The Controlling a Stage process will issue and receive Work Packages (which define and control the work to be done), with the Managing Product delivery process.

Once a decision has been taken to proceed with work and resources have been committed, the project management team must be focused on delivery within the tolerance laid down.

The Project Manager has the authority, providing the stage is forecast to fall within Tolerance, to take the appropriate corrective actions that they believe necessary.

Note that the Project Board Executive is responsible for the Business Case but regular management and updating of that document may be delegated to the Project Manager.

Controlling a Stage consists of the following key activities:

1. Authorizing work packages and ensuring that they are accepted by the Team Manager or specialist team

• Receiving regular feedback on the Work Package status, and assessing the bigger picture of actual stage progress

• Receiving advice of completed Work Packages and ensuring that they are complete and all arrangements have been carried out in a satisfactory manner

• Create regular Highlight Reports to keep the Project Board informed of stage progress – both in terms of actual progress and future forecast. The Highlight Report will also contain information such as budget, schedule, issue, risk, and tolerance situations.

• Reviewing the remainder of the stage and ensuring that it can be completed within tolerance, and taking corrective action if needed, when the stage is forecast to complete within tolerance

• Capture and examine project issues or risks including an impact analysis on each
  
  
• Escalate project issues or risks to the Project Board if tolerance is forecast to be exceeded, via an Exception Report

The process forms the core of the Project Manager’s effort on the project, being the process, which handles day-to-day management of the project.

Here is how the Controlling a Stage process supports the seven PRINCE2 Principles:

• Continued business justification. The Project Manager checks the Risk Register to assess their impact on the Business Case and if necessary escalates this to the Project Board. In addition the regular Highlight Reports provide the Project Board with the stage status and the Tolerance situation.
  
  
• Learn from experience. As part of the Review the stage status activity, the Project Manager updates the Lessons Log.

• Defined roles and responsibilities. When issuing a Work Package, part of its content agrees responsibilities for both managing and creating the products within it, and the roles required to carry out quality checking of the products.

• Manage by stages. The Controlling a Stage process, as its name suggests, ensures management and control of the stages products. The process ensures that each stage is completed successfully, and that effective and timely corrective action is taken whenever required.

• Manage by exception. Tolerances are set for each stage by the Project Board, and the Project Manager is responsible for managing the stage within tolerance bounds.

• Focus on products. Each Work Package includes a Product Description and its associated quality criteria to ensure the products are fit for purpose.

• Tailor to suit the project environment. The Controlling a Stage process is tailored via its Stage Plan to ensure a formality balance is struck to ensure it remains in control.
  
  The stage tolerance is set in consideration of the products to be developed and the stage environment. The Work Packages are also tailored to suit the nature and environment of the products to be created.
  
  

The importance of the PID as an input to Controlling a Stage

The Project Initiation Documentation is used throughout the Controlling a Stage process and as an input to the CS activities:

1. Authorize a Work Package. The PID will give information regarding the project controls, the quality standards, and how the products are to be handed over (via the Change Management Approach).

• Review the stage status. Check the Issue Register to see if any issues will impact the Business Case, Stage Plan or Project Plan.

• Report Highlights. This summary information about the stage will be contained in the Communication Management Approach
  
  
• Communication Management Approach to check the procedures and external parties that need to be informed. Report the status of risks as per the Risk Management Approach document
  
  
• Escalate issues and risks. For both, the Project Plan, Stage Plan and Business Case should be examined to check for tolerance deviations and options.

Controlling a Stage

• You understand how this process gives out work assignments, checks progress on them, and agrees their completion
  
  
• You understand how new issues and risks are dealt with
  
  
• You understand how to check that the stage is progressing in an acceptable manner or, and if it is going off track either dealing with the problem or referring it to the Project Board
  
  
• You understand the purpose of a Work Package both as an instruction and as a control
  
  
• You understand that a team may have one or more Work Packages within a stage
  
  
• You are familiar with the boundary between the Controlling a Stage and Managing Product Delivery processes as a customer/supplier interface
  
  
• You are familiar with the fact that this process is used for each stage within the project
  
  
• You are familiar with the activities within the process in terms of the purpose of each, and what management products each involves
  
  

You appreciate that the Controlling a Stage process will trigger the Managing a Stage Boundary process either to prepare for an end stage assessment, or because of an exception situation, where the Closing a Project process may be triggered instead

The Controlling a Stage process

Foundation Exam learning outcomes

• You understand how this process gives out work assignments, checks progress on them, and agrees their completion
• You understand how new issues and risks are dealt with
• You understand how to check that the stage is progressing in an acceptable manner or, and if it is going off track either dealing with the problem or referring it to the Project Board
• You understand the purpose of a Work Package both as an instruction and as a control
• You understand that a team may have one or more Work Packages within a stage
• You are familiar with the boundary between the Controlling a Stage and Managing Product Delivery processes as a customer/supplier interface
• You are familiar with the fact that this process is used for each stage within the project
• You are familiar with the activities within the process in terms of the purpose of each, and what management products each involves
• You appreciate that the Controlling a Stage process will trigger the Managing a Stage Boundary process either to prepare for an end stage assessment, or because of an exception situation, where the Closing a Project process may be triggered instead
• You understand the purpose and use of the Highlight Report, that it is created by the Project Manager, sent to the Project Board and others as laid down within the communications management approach
• You are familiar with the difference of project management actions covering the “Take corrective action” and “Escalate issues and risks” activities
• You are familiar with the use of tolerance and its influence on whether an issue should be escalated to the Project Board or dealt with by the Project Manager
• You are familiar with the formal and informal use of issues including the use of the Issue Report and the information it contains

Managing Product Delivery (MP)

The purpose of the Managing Product Delivery process is to control the link between the Project Manager and the Team Manager(s) by placing formal requirements on accepting, executing and delivering project work.

The role of the Team Manager(s) is to coordinate an area of work that will deliver one or more of the project’s products.

PRINCE2 takes the view that the job of the Project Manager is to manage the team, not to do the work of product creation.

MP allows a controlled break between the Project Manager and product creation/provision by third party or internal suppliers.

Managing  Product Delivery ensures that allocated work for the team is authorized and agreed so that all are clear what is to be produced and on what work effort, cost and timescales. In addition to ensure that the products meet expectations and are delivered within tolerance.

It is important that accurate and timely progress information is given to the Project Manager at a frequency as agreed within each Work Package.

If the Managing Product Delivery process uses eternal suppliers and they are not using PRINCE2, this Process can provide a statement of the required interface between the Team Manager and the PRINCE2 method.

The objective of this process is to ensure that planned products are created and delivered by:

• Making certain that work on products allocated to the team is authorized and agreed

1. Accepting and checking Work Packages

• Ensuring that work conforms to the requirements of interfaces identified in the Work Package

• Ensuring that the work is done

1. Assessing work progress and forecasts regularly

• Ensuring that completed products meet quality criteria

• Obtaining approval for the completed products.

The Stage Plan is split into Work Packages (each containing at least one Product Description); these are authorized by the project manager, and then given to the specialist team who needs to agree that they will carry out the Work Package.

Optionally, a Team Plan can be created as part of agreeing the Work Package.

Each Work Package includes a Product Description for each product to be created, and this includes how the quality for each product is to be checked and approved.

Once the Work Package has been agreed then work will start in creating the products within the Work Package and carrying out quality checks such that the products meet the quality criteria contained within each Product Description. Tolerances for the Work Package must be first agreed.

The Quality Register is updated if needed as part of the Accept a Work Package activity and is again updated as quality checks occur in the Execute a Work Package activity. As each product is approved, arrangements must be made so that the product is protected from change or damage. If the product type allows, the product will often be returned to the Configuration Librarian. The specialist team or the Team Manager must keep the Project Manager informed of the Work Package progress, by sending regular Checkpoint Reports (or meetings) to the project manager and keeping the Quality Register updated.

The Quality Register contains planned, and eventually, actual dates of all specialist product quality checks. Once all products have been approved and authorized, then the work package is complete. As each Work Package is finished, the Project Manager must agree that the work and product creation is satisfactory. This may trigger a new Work Package, or preparation for an End Stage Assessment.

Here is how the Managing Product Delivery process supports the seven PRINCE2 Principles:

• Continued business justification. This process does not directly involve the project Business Case (indeed, the suppliers may have their own business case).
  
  However, Managing Product Delivery supports continued business justification because of the formal link between this and the Controlling a Stage process
  
  The team can only start work (and hence consume cost and time) with the agreement and consent of the Project Manager.
  
  
• Learn from experience. The Checkpoint Reports notify the Project Manager of the Work Package status and includes and lessons from the team as part of the Work Package execution.

• Defined roles and responsibilities. The Work Package names who is authorized to manage the work, who should be providing or receiving information, who will carry out the quality checks, and who will approve each product.

• Manage by stages. This is not directly met within the Managing Product Delivery process, however, the process is only used within a given management stage.
  
  If future work is needed in a further stage by the team or organization, this will always form a separate Work Package in that future stage.

• Manage by exception. Tolerances are optionally set for each Work Package (at the discretion of the Project Manager)

• Focus on products. Each Work Package includes a Product Description and its associated quality criteria to ensure the products are fit for purpose.

• Tailor to suit the project environment. The Managing Product Delivery process is tailored in its level of formality, such as the level of detail contained within the Work Package, Checkpoint Reports and Team Plan, and whether one or more can be stated verbally rather than written down.

Managing Product Delivery

• You understand the Managing Product Delivery Work Package statement and objectives
  
  
• You appreciate that a team may work on more than one Work Package within a stage, that there may be more than one specialist team, and that therefore the Managing Product Delivery process may be used several times during a stage
  
  
• You appreciate that the Work Package provides instructions to build one or more products, and includes a copy of each relevant Product Description
  
  
• You appreciate that this process covers the work of the Team Manager, not the Project Manager, but if an individual is not available, that the Project Manager may fill both roles
   
• You understand the use of the Work Package as the Project Manager control mechanism
  
  
• You are aware that the “Execute a Work Package” activity covers the creation and testing of the specialist products, and additionally, that the Quality Review is a type of test, therefore that this technique would be used within this activity
  
  
• You’re aware that the results of a Quality Review are entered into the Quality Register along with any other less formal tests
  
  
• You understand the reasons why team Plans are optional, and the reasons that govern their choice or otherwise
  
  
• You know that the Checkpoint Reports and their frequency are detailed within each Work Package
  
  
• You appreciate that the specialist team creating the products within a Work Package may be done by internal or external staff, and as such, an external organisation may not need to be aware of nor use, the PRINCE2 method
  
  
• You understand the purpose and use of the Highlight Report, that it is created by the Project Manager, sent to the Project Board and others as laid down within the communications management Approach
  
  
• You are familiar with the difference of project management actions covering the “Take corrective action” and “Escalate issues and risks” activities
  
  
• You are familiar with the use of tolerance and its influence on whether an issue should be escalated to the Project Board or dealt with by the Project Manager
  
  

You are familiar with the formal and informal use of issues including the use of the Issue Report and the information it contains

The Managing Product Delivery process

Foundation Exam learning outcomes

• You understand the Managing Product Delivery Work Package statement and objectives
• You appreciate that a team may work on more than one Work Package within a stage, that there may be more than one specialist team, and that therefore the Managing Product Delivery process may be used several times during a stage
• You appreciate that the Work Package provides instructions to build one or more products, and includes a copy of each relevant Product Description
• You appreciate that this process covers the work of the Team Manager, not the Project Manager, but if an individual is not available, that the Project Manager may fill both roles
• You understand the use of the Work Package as the Project Manager control mechanism
• You are aware that the “Execute a Work Package” activity covers the creation and testing of the specialist products, and additionally, that the Quality Review is a type of test, therefore that this technique would be used within this activity
• You’re aware that the results of a Quality Review are entered in the Quality Register along with any other less formal tests
• You understand the reasons why team Plans are optional, and the reasons that govern their choice or otherwise
• You know that the Checkpoint Reports and their frequency are detailed within each Work Package
• You appreciate that the specialist team creating the products within a Work Package may be done by internal or external staff, and as such, an external organisation may not need to be aware of nor use, the PRINCE2 method

Managing a Stage Boundary (SB)

This process is only used for one of two purposes:

• The preparation for an End Stage Assessment leading to approval or otherwise of the Next Stage Plan, or...

• The preparation for an Exception Assessment - leading to approval or otherwise, of an Exception Plan.

However, its complete purpose is to enable the Project Board to be provided with sufficient information by the Project Manager so that it can review the success of the current stage, approve the next Stage Plan (or an Exception Plan), review the updated Project Plan, and confirm continued business justification and acceptability of the risks.

It’s important to understand, that IF the current Stage Plan is forecast to exceed tolerance bounds, and an Exception Plan is requested, then at an Exception Assessment (EXA), if that plan is approved, then, in effect, it replaces the remainder of the original Stage Plan and provides a plan for completing that stage:

I have also shown where Managing a Stage Boundary (SB) occurs, and that the final Stage Plan also includes those activities and cost to shut the project down in a controlled manner using the Closing a Project (CP) process.

This process provides the Project Board with key decision points on whether to continue with the project or not.

The objective of the Managing a Stage Boundary process is to:

1. Assure the Project Board that all products in the current stage have been completed and approved.

• Prepare the next Stage Plan

• Review and update if needed, the Project Initiation Documentation.

• Provide information to assess the project continued viability including the aggregated risk exposure

• Provide and lesson to help  this project in later stages or other projects

• Request authorization to start the next stage

For Exceptions:

• Prepare an Exception Plan

• Seek approval to replace Project Plan (for when Project Tolerance is to be exceeded), or the Stage Plan for the current stage with the Exception Plan.

The Project Manager will do most of the preparation work, assisted by Project Assurance, Project Support, and often, the specialist team in terms of the Team and Stage Plan.

SB is used at the end of each stage apart from the last – when the Closing a Project process is used to review the last stage progress.

In summary, SB is used to create and update all relevant project information so that the Project Board can make an informed choice about whether or not to proceed with the project.

Here is how the Managing a Stage Boundary process supports the seven PRINCE2 Principles:

• Continued business justification. The Project Plan is updated and the Business Case based on progress thus far and the remainder of the project. The Business Case is used as part of the information to decide whether to proceed or not.
  
  
• Learn from experience. The Lessons Log is used create the next Stage Plan, and to create the Lessons Report for or other projects.

• Defined roles and responsibilities. Reviewed at the End Stage Assessment/Exception Assessment and used for future stages in this project

• Manage by stages. Managing a Stage Boundary supports this by ensuring that at the end of each stage, the current stage must complete successfully, the next stage plan and associated documents must be updated and approved, before the project can transition into the next stage.

• Manage by exception. Managing a Stage Boundary supports this by creating an Exception Plan when requested by the Project Board, along with associated documentation ready for approval or otherwise by the Project Board.

• Focus on products. The next Stage Plan uses product based planning, and the current stage products must be approved before transition to the next stage is even considered.

• Tailor to suit the project environment. Each Stage Plan and the related Work Packages are tailored as needed to suit the project environment.

SB provides sufficient information to the Project Board to review the current stage, approve the next stage plan, review the updated Project Plan and Business Case to ensure continued viability, and that the aggregated risks and countermeasures are acceptable.

The above diagram looks complicated, but it is really straight forward - starting top left:

As the stage boundary of the current stage approaches, the Project Manager creates the Next Stage Plan, and as a consequence this includes new or modified products, and their Product Descriptions (PD) and activities.

Notice that when in the Initiating a Project process, the Next Stage Plan will be triggered from that process rather than from Controlling a Stage. The quality checking activities for the new Product Descriptions are entered on the Quality Log.

Configuration Item Records are created for the products, and the PID is updated. As a result of planning, the Risk Register is updated with new risks and any issues captured on the Issue Register.

Now the Project Manager needs to ‘harmonize’ the Project Plan as a result of the new Stage Plan plus to capture the latest end of stage actuals and new forecast, and again any new risks or issues from the Project Plan are entered in their Registers.

Next we need to update the Business Case. The Executive is responsible for this, so the Project Manger consults with that role to review and update it.

The Benefits Management Approach may need to be updated with the results from any benefit reviews and to acknowledge any Products that have gone into operational status during the stage.

The results of the stage (via the End Stage Report) should be reported back to the Project Board so that progress is clearly visible to the project management team.

The Project Manager will want to request a Product Status Account from project support to confirm the true status of all the stage products.

Configuration Item Records are amended or created, and the Benefits Review Plan updated

Also, the End Stage Report is generated to summarize the stage and project status, and a Lessons Report is created if required.

This then triggers the Project Manger to request to approve the next Stage Plan at an End Stage Assessment.

So what if instead of reaching the stage end, the exception process has been triggered? Again, referring to the above diagram, the Project Board using the Directing a Project process, requests the Project Manager to create an Exception Plan.

As you can see, it is a very similar set of product that are created or updated.

Once the Exception Plan is created, the following activities are the same as for a next Stage Plan, resulting in an End Stage Report, but this time requesting the approval of the Exception Plan which will be reviewed at an Exception Assessment.

Here are how the following key documents inputs are used in the Managing a Stage Boundary process:

Project Initiation Documentation. This includes the Quality, Risk, Configuration and Communication Strategies in particular. Used as an input in its entirety when creating any one of the types of plan, since all of the Approach documents will be used as well as the Business Case, and so on. Those activities are, Plan the next stage, Update the Project Plan, and Produce an Exception Plan.

Business Case. This is used as an input to the End Stage Report in the Report Stage end activity.

Communication Management Approach. This is used as an input to the End Stage Report to check who should receive it.

Next Stage Plan. This is used to update the Project Plan.

Exception Report. This is used as an input to the Product an Exception Plan activity.

Configuration Item Records. These are used as an input to Plan the Next Stage and Produce an Exception Plan as there will be new or modified products.

Product Status Account. This is used to inform the End Stage Report of the latest product status as in input to the Report Stage end activity.

The Benefits Management Approach. This is used as an input and updated with latest status in the Update the Business Case activity and also as an input to inform the End Stage Report in the Report Stage end activity.

Issue Register and the Risk Register. These are used as an input to all the SB activities apart from the Update the Project Plan activity. These are updated in all the activities apart from the Report stage end activity.

Lessons Log. This is used as input for the Next Stage Plan in the Plan the next stage activity, and as an input to create the End Stage Report in the Report stage end activity.

In summary, SB is used to create and update all relevant project information so that the Project Board can make an informed choice about whether to proceed with the project.

Managing a Stage Boundary

• You have a high-level understanding of how this process is used to first look back, determine where the project is now, and then look ahead for the forecast
  
  
• You understand the purpose and objectives statements for this process
  
  
• You understand how this process interacts with the PRINCE2 principles and themes
  
  
• You can explain the two triggers of the Managing a Stage Boundary process
  
  
• You appreciate that this process is not used within the last stage of a project but rather that the Closing a Project process is triggered in its place
  
  
• You fully understand the activities within this process, their suggested sequence, as well as who is doing what within each activity. This is usually the Project Manager.
  
  
• You understand which management products are used as an input into this process, as well as which products are being created
  
  
• You appreciate that an exception Plan may include an adjusted project Plan, possibly team Plans, or a revised stage Plan
  
  
• You understand the relationship between using this process at the end of a stage, or part way through the stage due to an exception
  
  

You understand why that if an exception Plan is requested, it will only need to cover future work within the stage, and not the work already covered as this will have been closed down with an accompanying End Stage Report

The Managing a Stage Boundary process

Foundation Exam learning outcomes

• You have a high-level understanding of how this process is used to first look back, determine where the project is now, and then look ahead for the forecast
• You understand the purpose and objectives statements for this process
• You understand how this process interacts with the PRINCE2 principles and themes
• You can explain the two triggers of the Managing a Stage Boundary process
• You appreciate that this process is not used within the last stage of a project but rather that the Closing a Project process is triggered in its place
• You fully understand the activities within this process, their suggested sequence, as well as who is doing what within each activity.  This is usually the Project Manager.
• You understand which management products are used as an input into this process, as well as which products are being created
• You appreciate that an exception Plan may include an adjusted project Plan, possibly team Plans, or a revised Stage Plan
• You understand the relationship between using this process at the end of a stage, or part way through the stage due to an exception
• You understand why that if an Exception Plan is requested, it will only need to cover future work within the stage, and not the work already covered as this will have been closed with an accompanying End Stage Report

Closing a Project (CP)

The purpose of this process is to provide a fixed point at which acceptance for the project product is confirmed, and to recognize that the objectives set out in the original PID have been met – or that the project has nothing more to contribute.

One of the defining features of a project is that it is finite -- in that it has a start and an end. If the project loses this distinctiveness, it loses some of its effectiveness of a purely operational management approaches.

This process may be used for either a "natural" close or a premature close should one ever be necessary. Closure activities should be planned and included as part of the final Stage Plan.

As part of closure, the project management team can be disbanded and project costs should no longer be incurred.

Closing a Project is triggered during the last stage after all specialist products have been created.

Before closure of the project can be recommended (via a closure recommendation sent to the Project Board), the Project Manager must ensure that the expected results have all been achieved and delivered.

The objectives of Closing a Project are to:

• Gain user acceptance of the project’s products

• Ensure the host site is able to support the products

• Review the project performance against its baselines

1. Assess any benefits that have already been realized

• Update the forecast and plan a review for remaining benefits

1. Address all open issues and risks with follow-on actions

Here is how the Closing a Project process supports the seven PRINCE2 Principles:

• Continued business justification. When undertaking the Evaluate the project activity, the expected benefits in the Business Case should be assessed to confirm which have been realized and which have not.
  
  
• Learn from experience. The Lessons Report is created by the Project Manager containing lessons that could be applied to future projects.

• Defined roles and responsibilities. The Benefits Review Plan will identify who is to be responsible for continuing benefit realization after project closure including identifying support and maintenance responsibilities via the Change Management Approach document.

• Manage by stages. Closing a Project includes the closure activities of the final project stage.

• Manage by exception. The Closing a Project activities take place within the last stage, and as such, if there is a threat of exceeding tolerance bounds, an Exception Report is raised to trigger the exception process.

• Focus on products. The Hand over product activity ensures there are the expected products by gaining and Acceptance record, and the Closing a Project includes completion of several management products.

• Tailor to suit the project environment. The final Stage Plan will have been tailored to suit the formality, environment and logistics of project closure.

Closing a Project should not be used in a final stage solely for closing the project but should always be used within the last stage where specialist products are being created via the Managing Product Delivery process, and the Closing a Project process is triggered once all the specialist products are complete.

The objective of Closing a Project is to have a fixed point at which the project product is accepted, and that this is confirmed, and to agree that the Project Initiation Documentation objectives have been met.

This process is also used should a need arise for a premature close.

The process covers the Project Manager’s work to wrap up the project either at its end or at a premature close.

Most of the work is to prepare input to the Project Board to obtain its confirmation that the project may close.

With reference to the above diagram, here are the activities within Closing a Project:

Prepare planned closure. Update the Project Plan with actual data, request a Product Status Account to determine that the products have meet their quality criteria and have been approved.

Confirm that the project has delivered in the Project Product Description.

Prepare premature closure. This is the same as above, but since it is premature, many of the intended objectives were either not met, or could not be met. So the Issue Register is updated to record the premature close, the Project Plan is updated with actuals, a Product Status Account is requested to check what is done and what is left,

Hand over products. The products must be passed to an operational and maintenance environment prior to the project being closed. When handing over the products, the Benefits Review Plan may need updating to include the post-project benefit reviews.

The Change Management Approach should be checked to see how the products are to be handed over, and the Configuration Item Records updated to show that each product’s status is now operational.

Using the Issue Register and the Risk Register, any uncompleted work, issues and risks should be included in the prepare follow-on action recommendations.

Evaluate the project. Here, the Project Manager, in consultation with the project management team, prepares the End Project Report and the Lessons Report which uses the Lessons Log as its source information..

Recommend project closure. The Project Manager raises a draft project closure notification along with a closure recommendation to the Project Board and uses the Communication Management Approach document to identify all those who need to know the project is closing.

All Registers and Logs are closed and project information is archived as per the Change Management Approach to permit future audit of the project.

Closure activities should have been included within the final stage plan, the project team can now be disbanded, and project costs should no longer be incurred.

The Executive should inform corporate or programme management that the project has closed.

Closing a Project

• You can identify the Closing a Project process objectives and the purpose statement, including if any errors are included within the exam scenario
  
  
• You understand the five activities within this process, what happens in each and who is responsible. This will typically be the Project Manager with Project Assurance but may also include Project Support
  
  
• You understand how the Closing a Project process uses the management products that feed into it
  
  
• You understand the purpose of the End Project Report as the Project Manager’s record of the project performance and final metrics
  
  
• You are aware that this process compares achievements against the original baselined Project Initiation Documentation (PID) as well as the latest PID version
  
  
• You are familiar with the two triggers for this process; able to recognize when the last stage is complete from the Controlling a Stage process, or as a Project Board instruction to prematurely close the project
  
  
• You understand that a premature close can be instructed by the Project Board at any time via the “Giving ad hoc direction” activity because they chose not to authorize the remaining stage work, or that they order project closure from their activity “Authorize a Stage or Exception Plan”
  
  
• You understand that the Project Manager is responsible for closing the project itself as well as preparing information such as the End Project Report for the Project Board
  
  
• You are aware that any benefits realized at this point need to be measured and reported at this time
  
  
• You understand that there is no End Stage Report for the final stage as this is replaced by the End Project Report covering the whole of the project including the last stage
  
  
• You understand the details of the activity follow on action recommendation as a mechanism to pass non-project work on to those responsible for operational use of the final product