Prince2017 part 2

1
Trainer: Robert Edward Pinnington

2
Introduction
Project management with PRINCE2
Principles
Tailoring & adopting PRINCE2
Introduction to PRINCE2 themes
Business case
Organization
Quality
Plans
Risk
Change
Progress
Agenda (See Part 1)

3
Introduction to processes
Starting up a project
Directing a project
Initiating a project
Controlling a stage
Managing product delivery
Managing a stage boundary
Closing a project
Considerations for organizational adoption
Agenda (See Part 2)

4
The PRINCE2 journey
PRINCE2 process model
Structure of the process chapters
Tailoring the processes

5
The PRINCE2 journey
PRINCE2 is a process-based approach for project management. A process is a
structured set of activities designed to accomplish a specific objective. It takes one or
more defined inputs & turns them into defined outputs. There are seven processes in
PRINCE2, which provide the set of activities required to direct, manage & deliver a
project successfully.

6
The PRINCE2 journey
Pre-project
In the beginning, someone has an idea or a need. The trigger for the project may
come from new business objectives, responding to competitive pressures, changes in
legislation or a recommendation in a report or an audit. In PRINCE2, this trigger is
called a project mandate.
Initiation stage
When a decision has been made to go ahead with the project, it needs to be planned
at an appropriate level of detail. Funding needs to be obtained & appropriate controls
should be defined to ensure that the project proceeds in accordance with the wishes
of those people paying for the project & those who will make use of what the project
delivers. The initiation stage culminates in the production of the PID, which is
reviewed by the project board to decide whether to authorize the project. As the
contents of the Pl D are likely to change throughout the project (under change
control), this version of the PID is preserved as input for later performance reviews.

7
The PRINCE2 journey
Subsequent stages
The project board delegates day-to-day control to the project manager on a
management-stage-by-management stage basis. The project manager needs to
assign work to be done, ensure that the outputs of such work (products) meet
relevant specifications, & gain suitable approval where appropriate. At this point,
products may be transitioned into operational use by corporate, programme
management or the customer. Towards the end of each management stage, the
project manager requests permission to proceed to the next management stage by
reporting how the management stage performed, providing an update to the business
case & planning the next management stage in detail. The project manager provides
the information needed by the project board in order for it to assess the continuing
viability of the project & to make a decision to authorize the next management stage.

8
The PRINCE2 journey
Final stage
As a project is a temporary undertaking, towards the end of the final management
stage (when the project manager has gained approval for all the project's products) it
is time to start the closing a project process. The project board needs to be satisfied
that the recipients of the project's products are in a position to own & use them on an
ongoing basis. Closure activities include planning post-project benefits reviews to
take place for those benefits that can only be assessed after the products have been
in use (and therefore after the project has closed).
Post-project
The project is typically contributing towards the benefits defined by corporate,
programme management or the customer.
•confirming that the planned benefits have been achieved.
•identifying which planned & unexpected benefits have not been achieved & agreeing
a follow-up action plan.
•identifying any benefits that have been achieved & any dis-benefits that resulted.

9
PRINCE2 process model
The processes are aligned with the management levels of corporate, programme
management or the customer, directing, managing & delivering. The triggers between
the processes are shown.

10
Structure of the process chapters
Each process within PRINCE2 is described using the following structure & format:
•Purpose Describes the reason for the process.
•Objective Describes the specific objectives to be achieved by the process.
•Context Puts each process in context with the other processes & activities going on
within the project & from corporate, programme management or the customer.
•Activities Each PRINCE2 process comprises a set of activities, which may be run in
series or in parallel. PRINCE2 activities comprise a set of recommended actions
designed to achieve a particular result.
•Tailoring guidelines Describes the approaches that can be used to tailor a process

11
Tailoring the processes
PRINCE2 requires that project management processes are as simple as possible &
that they reflect the needs of the project. There may be some activities, however,
especially relating to governance which may need to be prescriptive. This happens
especially where they interface to a higher-level organization's process, such as for
procurement or finance.
A tailored PRINCE2 process should reflect any tailoring of the roles, products,
themes (as implemented through management approaches, procedures & controls) &
terminology. As terminology can be tailored, so can the names of the processes.

12
Purpose
Objective
Context
Activities
Tailoring guidelines

13
Purpose
The purpose of the starting up a project process is to ensure that the prerequisites for
initiating a project are in place by answering the question: Do we have a viable &
worthwhile project? The decision to start the project must be explicit; the activities
from starting up a project happen before this decision.
Nothing should be done until certain base information needed to make rational
decisions about the commissioning of the project is defined, key roles &
responsibilities are resourced & allocated, & a foundation for detailed planning is
available.

14
Objective
The objective of the starting up a project process is to ensure that:
•there is a business justification for initiating the project (documented in an outline
business case).
•all the necessary authorities exist for initiating the project.
•sufficient information is available to define & confirm the scope of the project (in the
form of a project brief).
•the various ways the project can be delivered are evaluated & a project approach
selected.
•individuals are appointed who will undertake the work required in project initiation
and/or will take significant project management roles in the project.
•the work required for project initiation is planned (documented in a stage plan).
•time is not wasted initiating a project based on unsound assumptions regarding the
project's scope, timescales, acceptance criteria & constraints.

15
Context
Projects can be identified in a variety of ways & thus have a wide variation in the
information available at the time of start-up. In PRINCE2, the trigger for the project is
referred to as the project mandate. This is provided by the responsible authority that
is commissioning the project, typically corporate, programme management or the
customer.

16
Activities
The activities within the starting up a project process are likely to be shared between
corporate, programme management or the customer, the executive & the project
manager. The activities are to:
•appoint the executive & the project manager.
•capture previous lessons.
•design & appoint the project management team.
•prepare the outline business case.
•select the project approach & assemble the project brief.
•plan the initiation stage.

17
Activities: Appoint the executive & the project manager
To get anything done in the project, a decision maker with appropriate authority is
needed (the executive) who represents the interests of the business stakeholder(s).
The appointment of the executive is a prerequisite to ensuring that the project is
justified. The appointment of a project manager allows for the project to be managed
on a day-to-day basis on behalf of the executive.

18
Activities: Capture previous lessons
A number of lessons may have been provided by other projects, corporate,
programme management or the customer, & external organizations. These lessons
may include weaknesses or strengths of the processes, & procedures, techniques &
tools used, when they were used, how they were used & by whom.
The design of the project management team, the outline business case, the contents
of the project brief & the stage plan for the initiation stage can be influenced by
lessons from previous projects.

19
Activities: Design & appoint the project management team
The project needs the right people in place, with the authority, responsibility &
knowledge to make decisions in a timely manner. The project management team
needs to reflect the interests of all parties who will be involved, including business,
user & supplier interests. It is essential for a well -run project that every individual
involved in the management of the project understands & agrees who is accountable
to whom for what, who is responsible for what, & what the reporting & communication
lines are.

20
Activities: Prepare the outline business case
When setting up, & particularly while running the project, it is all too easy to
concentrate on what is being done & how it is to be done, while ignoring why it needs
to be done. Given the information available, the outline business case is likely to be
only a high-level view at this time. It provides an agreed foundation for a more
detailed business case developed in the initiating a project process.

21
Activities: Select the project approach & assemble the project brief
Before any planning of the project can be done, decisions must be made regarding
how the work of the project is going to be approached. The way in which the work is
to be conducted will depend on any customer or supplier standards, practices &
guidelines. These should be captured in the project brief as part of the project
approach, as they will influence the project approaches to be created in the initiating
a project process. It also ensures that the project approach is clearly understood
between customer & supplier, & does not jeopardize the project in any way.

22
Activities: Plan the initiation stage
Initiating a project takes time & consumes resources. The work should be planned &
approved to ensure that initiation is not aimless & unstructured. If the project is part of
a programme, the end date for the initiation stage should be checked against that
held in the programme's plans. The stage plan for the initiation stage will also give the
programme management team warning of any requirements from the programme.

23
Tailoring guidelines: General considerations
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 interface with the
directing a project process when a request to initiate a project is submitted.
Tailoring the roles in starting up a project
If a project manager has not been appointed at the start of this process, the required
management products may be created by the executive or anyone appointed by
them.

24
Tailoring guidelines: Common situations
Starting up a simple project
If the risks are acceptable, the starting up a project process may be handled in a less
formal manner than for larger, more risky projects.
Starting up projects using an agile delivery approach
The suitability of using an agile way of working needs to be assessed by looking at
what agile ways of working exist or need to exist, & their respective advantages &
disadvantages.
Starting up projects from a supplier perspective
From a supplier perspective, the starting up a project process will take place pre-
contract & is typically in response to the customer's request for information or a
proposal.
Starting up projects within a programme
The PRINCE2 process most affected by working in a programme will be starting up a
project.

25
Purpose
Objective
Context
Activities
Directing a project

26
Purpose
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 & exercising overall
control while delegating day-to-day management of the project to the project
manager.
Directing a project

27
Objective
The objective of the directing a project process is to ensure that:
•there is authority to initiate the project.
•there is authority to deliver the project's products.
•management direction & control are provided throughout the project's life.
•the project remains viable.
•corporate, programme management or the customer has an interface to the project.
•there is authority to close the project.
•plans for realizing the post-project benefits are managed & reviewed.
Directing a project

28
Context
The directing a project process covers the activities of the project board & is not
concerned with the day-today activities of the project manager. The project board
manages by exception: it monitors via reports & controls through a small number of
decision points. There should be no need for other 'progress meetings' for the project
board. The project manager will inform the board of any exception situation. It is also
important that levels of authority & decision-making processes are clearly identified.
Directing a project

29
Activities
The activities within the directing a project process are project board oriented & are
to:
•authorize initiation.
•authorize the project.
•authorize a stage or exception plan.
•give ad hoc direction.
•authorize project closure.
Directing a project

30
Activities: authorize initiation
Projects take time & cost money to initiate, so the activities for initiation should be
planned, monitored & controlled . The project board activity to authorize initiation
ensures that such investment is worthwhile. When a request to initiate a project is
received from starting up a project, the project board must decide whether to allow
the project to proceed to the initiation stage
Directing a project

31
Activities: authorize the project
This activity will be triggered by a request from the project manager for authorization
to deliver the project, & may be undertaken in parallel with authorizing a stage or
exception plan. The objective of authorizing the project is to decide whether to
proceed with the rest of the project. The project board has to confirm that:
•an adequate & suitable business case exists & that it shows a viable project.
•the project plan & the benefits management approach are adequate to deliver the
business case.
•the project's approaches & controls support delivery of the project plan.
•the mechanisms for measuring & reviewing the projected benefits are established &
planned.
Directing a project

32
Activities: authorize a stage or exception plan
It is important that a management stage starts only when the project board says it
should. The project board authorizes a management stage by reviewing the
performance of the current stage & approving the stage plan for the next stage.
Approval of stage plans occurs at the end of every management stage except the last
one.
Directing a project

33
Activities: give ad hoc direction
Project board members may offer informal guidance or respond to requests for
advice at any time during a project. The need for consultation between the project
manager & project board is likely to be particularly frequent during the initiation stage
& when approaching management stage boundaries. Ad hoc direction may be given
collectively or by individual project board members.
Directing a project

34
Activities: authorize project closure
The controlled close of a project is as important as the controlled start. There must
be a point when the objectives in the original & current versions of the PID & project
plan are assessed in order to understand:
•whether the objectives have been achieved.
•how the project has deviated from its initial basis.
•that the project has nothing more to contribute.
Directing a project

35
After approval to initiate the project has been confirmed, care should be taken to
ensure the integrity of the interface to the initiating a project, managing a stage
boundary & closing a project processes when the formal decision to start the next
management stage or close the project is made. The degree of formality may differ in
different circumstances provided decisions are explicit & traceable, ranging from
verbal advice & decisions to those which are formally documented in email, meeting
minutes or other traceable formats.
Tailoring the roles in directing a project
All the activities in this process are the accountability of the executive but the actual
work may be done by others. It should, however, be noted that the project manager
should not take any decisions or give approval or direction on matters which are the
responsibility of the executive; the roles of executive & project manager must be kept
separate.
Directing a project

36
Directing a simple project
Directing a simple project is likely to be less formal than for a larger project. If the
project is a two-stage project, there will be no decisions requested from managing
stage boundaries except when an exception plan is needed.
Directing projects when using an agile approach
When using an agile approach, direction & decisions need to happen quickly. It is
vital to ensure that management by exception is operating effectively for the whole
project team as this creates an environment conducive to the agile way of working
where people are empowered & self-organized. In terms of progress reporting, the
project board should expect emphasis to be placed on the quality & amount of the
requirement being delivered as, for agile delivery, times & cost are fixed.
Directing a project

37
Directing a project from a supplier perspective
If the project is run from a supplier perspective, the executive looks after the interests
of that supplier organization. The supplier may also provide a person to act as senior
supplier on the project board of the customer's project.
In the early stages of a project, it may not be possible to appoint a contractor or
supplier representative to the role of senior supplier on the project board, simply
because no supplier or contractor has been selected. In such circumstances a person
should be appointed to look after their interests until such an appointment can be
made.
Directing a project within a programme
The choice of individuals to undertake the project board roles is open. For example,
the executive may be the same person as the programme manager. The key is that
each role holder has no conflicts of interest & it is clear who they report to in the
respective programme & project organization structures; accountabilities with respect
to governance should be explicit.
Directing a project

38
Purpose
Objective
Context
Activities

39
Purpose
The purpose of the initiating a project process is to establish solid foundations for the
project, enabling the organization to understand the work that needs to be done to
deliver the project's products before committing to a significant spend.

40
Objective
The objective of the initiating a project process is to ensure that there is a common
understanding of:
•the reasons for doing the project, the benefits expected & the associated risks.
•the scope of what is to be done & the products to be delivered.
•how & when the project's products will be delivered & at what cost.
•who is to be involved in the project decision-making.
•how the quality required will be achieved.
•how baselines will be established & controlled.
•how risks, issues & changes will be identified, assessed & controlled.
•how progress will be monitored & controlled.
•who needs information, in what format & at what time.
•how the corporate, programme management or customer method will be tailored to
suit the project.

41
Context
Initiating a project is aimed at laying down the foundations in order to achieve a
successful project. Specifically, all parties must be clear on what the project is
intended to achieve, why it is needed, how the outcome is to be achieved & what their
responsibilities are, so that there can be genuine commitment to it.
The initiating a project process enables the project board, via the directing a project
process to decide whether or not the project is sufficiently aligned with corporate,
programme management or customer objectives to authorize its continuation. If,
instead, the organization proceeds directly from starting up a project to controlling a
stage, then it may risk committing significant financial resources to a project without
fully understanding how its objectives will be achieved.
All activities within the initiating a project process need further consideration if the
relationship between the customer & the supplier is a commercial one.

42
Context

43
Activities
The activities within the initiating a project process are project manager oriented &
are to:
•agree the tailoring requirements.
•prepare the risk management approach.
•prepare the change control approach.
•prepare the quality management approach.
•prepare the communication management approach.
•set up the project controls.
•create the project plan.
•refine the business case.
•assemble the project initiation documentation.

44
Activities: agree the tailoring requirements
The project manager may need to tailor how the project is directed & managed in
order to recognize internal & external factors that affect the way in which the project is
delivered. Any deviations from the organization's standard project management
approach must be documented & agreed.

45
Activities: prepare the risk management approach
The risk management approach describes the goals of applying risk management,
the procedure that will be adopted, the roles & responsibilities, the risk tolerances, the
timing of risk management activities, the tools & techniques that will be used & the
reporting requirements.

46
Activities: prepare the change control approach
Change control is essential for the project to maintain control over its management &
specialist products. The level of control required will vary from project to project. The
maximum level of control possible is determined by breaking down the project's
products until the level is reached at which a component can be independently
installed, replaced or modified. However, the level of control exercised will be
influenced by the importance of the project & the complexity of the relationship
between its products

47
Activities: prepare the quality management approach
A key success factor of any project is that it delivers what the user expects & finds
acceptable. This will only happen if these expectations are both stated & agreed at
the beginning of the project, together with the standards to be used & the means of
assessing their achievement. The purpose of the quality management approach is to
ensure such agreements are captured & maintained.

48
Activities: prepare the communication management approach
The communication management approach addresses both internal & external
communications. It should contain details of how the project management team will
send information to, & receive information from, the wider organization(s) involved
with, or affected by, the project. In particular, if the project is part of a programme,
details should be given on how information is to be fed to the programme.

49
Activities: set up the project controls
The level of control required by the project board after initiation needs to be agreed &
the mechanism for such controls needs to be established, as does the level of control
required by the project manager of the work to be undertaken by team managers.
Project controls enable the project to be managed in an effective & efficient manner
that is consistent with the scale, risks, complexity & importance of the project.
Effective project controls are a prerequisite for managing by exception

50
Activities: create the project plan
Before committing to major expenditure on the project, the timescale and resource
requirements must be established. This information is held in the project plan and is
needed so that the benefits management approach can be prepared and the
project board can control the project. Planning is not an activity that the project
manager performs in isolation but, rather, something that should be done with close
involvement of the user(s) and supplier(s).

51
Activities: refine the business case
The outline business case produced during starting up a project needs to be updated
to reflect the estimated time & costs, as determined by the project plan, & the
aggregated risks from the updated risk register. The detailed business case will be
used by the project board to authorize the project & provides the basis of the ongoing
check that the project remains viable. For more details on business justification,

52
Activities: assemble the project initiation documentation
There needs to be a focal point at which all information relating to the 'what, why,
who, how, where, when & how much' of the project is:
•gathered for agreement by the key stakeholders.
•available for guidance & information for those involved in the project.
This information is collated into the PIO. The PIO is an aggregation of many of the
management products created during initiation & used to gain authorization for the
project to proceed . It is not necessarily (and rarely) a single document, but a
collection of documents or other forms of information (such as flip-charts, data in
software tools, etc.)

53
Activities: assemble the project initiation documentation

54
Tailoring guidelines : General considerations
project's circumstances. The number of management products created in this
process can look daunting and, together, may imply a level of de tail that is not
always needed. This process lays the foundation & it is here that tailoring for the
project is primarily decided.
Tailoring is needed to suit a project's circumstances but it may not always be
obvious, at the start of initiation, what the relevant factors are. At such an early stage
in the project, there may not be enough information; tailoring needs will emerge as
the initiation work progresses. For this reason, it is better to start 'simple' & then
elaborate if needed, rather than create a management environment suitable for a
hypothetical major project.

55
Tailoring products in initiating a project
Just because PRINCE2 has separate management products in this process, it does
not mean each management product is reflected in a discrete & separate document
or even as a document at all, where information & collaborative systems are used.
Tailoring roles in initiating a project
The PRINCE2 manual shows the creation of these management products as the
responsibility of the project manager. Project support may be responsible for some
supporting products, but in all cases the project manager is responsible to the
executive for how the project is run. The project manager may therefore assign
whoever is appropriate to the tasks. Often support may be provided by a higher-level
programme office or similar.

56
Initiating a simple project
Initiating a simple project is likely to be less formal than for a larger project, with
management products combined into a small number of documents. The project
manager may also be acting as a team manager for one or more work packages.
Initiating projects when using an agile approach
At the start of the project it may not be certain that an agile delivery approach is
appropriate for some or all of the specialist products. It is during the initiating a project
process that the decision is likely to be made on what parts of a project are best
approached using agile & which not. Agile is more likely to be appropriate when the
end product needs to be developed iteratively, provided the project management
team understand the approach & implement a control system which deals with a
more volatile environment.

57
Initiating a project from a supplier perspective
Some of the initiating a project process activities will be undertaken pre-contract as
the supplier will need to formulate the approaches, plans & controls in order to
assess the viability & desirability of undertaking the proposed contract, together with
the costs & prices of the solution being proposed. The initiating a project process is
not completed, however, until contract negotiation has concluded & the customer's
project board authorizes the project.
Initiating a project within a programme
All the guidance provided above is applicable to a project within a programme. The
main difference is that the programme manager may prescribe or constrain the
project manager's choices. In some cases, the PID (or parts of it, such as the detailed
business case) might be produced by a member of the programme team, & may even
exist in detail prior to initiating the project or be included in the programme's business
case.

58
Purpose
Objective
Context
Activities
Controlling a stage

59
Purpose
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, & take corrective
actions to ensure that the management stage remains within tolerance.
Controlling a stage

60
Objective
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 & products agreed at the start of the management stage is
monitored to avoid uncontrolled change & loss of focus
•risks & 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 & time agreed, & ultimately in support of the
achievement of the defined benefits
•the project management team is focused on delivery within the tolerances laid down.
Controlling a stage

61
Context
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.
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 & control the work to be done, & 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 & 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.
Controlling a stage

62
Context
Controlling a stage

63
Activities
Controlling a stage activities are project manager oriented and comprise:
•authorize a work package.
•review work package status.
•receive completed work packages.
•review the management stage status.
•report highlights.
•capture and examine issues and risks.
•escalate issues and risks.
•take corrective action.
Controlling a stage

64
Activities: 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 & continues with the
consent of the project manager. The vehicle for this is the production, execution &
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.
.
Controlling a stage

65
Activities: authorize a work package
Controlling a stage

66
Activities: review work package status
This activity provides the means for a regular assessment of the status of the work
package(s). The frequency & formality of this activity will usually be aligned with the
frequency of reporting defined in the work package(s) & supported by the stage plan
for the current management stage.
PRINCE2 recommends the following actions for each work package in progress:
•Collect & review progress information from the checkpoint report for the work
package being executed.
•assess the estimated time & 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 & to budget
Controlling a stage

67
Activities: review work package status
Controlling a stage

68
Activities: 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 & approved. When approved, any
subsequent changes to the product(s) must pass through change control This should
be an automatic part of any change control method being used.
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
Controlling a stage

69
Activities: receive completed work packages.
Controlling a stage

70
Activities: 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 & reacting to events.
In order to make informed decisions & exercise rational control, it is necessary to
compare what has actually happened with what was expected to happen & what
might happen next (including any issues & risks). It is therefore essential to have a
steady flow of information that provides an overall view of progress & simple, robust
monitoring systems to supply that information. The objective of this activity, therefore,
is to maintain an accurate & current picture of progress on the work being carried out
& 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 & risks.
Controlling a stage

71
Review progress for the management stage:
•review checkpoint reports for the period.
•review the current stage plan forecast & actuals.
•request a product status account from project support to identify any variation
between planned progress, reported progress & actual progress.
•check for any quality issues shown in the quality register.
•check the risk register for any new or revised risks & assess their impact.
•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 & 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, & execute them as necessary.
Controlling a stage

72
.
Controlling a stage

73
Activities: report highlights
The project manager must provide the project board with summary information about
the status of the management stage & project, & distribute other information to
stakeholders at a frequency documented in the communication management
approach (as defined by the project board).
•Assemble the information from the checkpoint reports, risk register, issue register,
quality register, lessons log, product status account & any significant revisions to the
stage plan for the current reporting period
•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• 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 & any other recipients identified in
the communication management approach.
Controlling a stage

74
Activities: report highlights
Controlling a stage

75
Activities: capture & examine issues & risks
In the course of managing the project, various issues will occur & risks may be
identified. They will arrive in an ad hoc manner & will need to be captured in a
consistent & 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 & then
assessed for its impact. For more details on risk management
Controlling a stage

76
If an issue can be dealt with by the project manager informally, then this should be
done, & a note made in the daily log
For issues that need to be managed formally:
•check the requirements of the issue management & 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 &
check the communication management approach to see whether there are any
external parties that need to be informed of the issue.
Controlling a stage

77
For risks
•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 &
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
Controlling a stage

78
Controlling a stage

79
Activities: escalate issues & 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 &
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 & risks is good practice & should not be seen as
failure. The earlier that issues are escalated, the more time is available to implement
any corrective actions
Controlling a stage

80
•Examine the stage plan to define the extent of the deviation & the unfinished
products, & to extrapolate what would happen if the deviation were allowed to
continue.
•Examine the project plan for the project status & overall effect of any deviation
(using the current baseline of the PID).
•Determine the options for recovery & 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 & 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 This may include:
•Requesting more information or more time to consider its response
•Approving, deferring or rejecting a request for change
Controlling a stage

81
Controlling a stage

82
Activities: take corrective action.
Changes & adjustments to the project need to be made in a considered & rational
way, even when they appear to be easily manageable & within tolerances. In taking
corrective action, the objective is to select and, within the limits of the management
stage & project tolerances, implement actions that will resolve deviations from the
plan. Corrective action is triggered during the review of the management stage status
& typically involves dealing with advice & guidance received from the project board, &
with issues raised by team managers.
Controlling a stage

83
•Collect any relevant information about the deviation.
•Identify the potential ways of dealing with the deviation & select the most appropriate
option.
•Trigger corrective action via authorizing a work package
•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 & 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.
Controlling a stage

84
Controlling a stage

85
The work packages are fundamentally important to this process as they relate to the
PRINCE2 principle to focus on products.
Tailoring products in controlling a stage
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.
The frequency of highlight reporting may change to suit the risk profile & output being
created . This is documented in the communication management approach in the
PID. Additional information, such as KPls, may be added or referenced if it provides
clarity. Highlight reports may be in the form of wall charts or Kanban boards.
Controlling a stage

86
Issue report An issue report is simply a view of the issue register with additional
information covering an impact analysis, recommendation & 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.
Controlling a stage

87
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 & their role is rather to see that they are defined & reviewed
rigorously.
Controlling a stage

88
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.
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 & making full use of the most effective visual communication channels.
Further to this, the use of regular reviews & retrospectives along with setting the
appropriate tolerances (based primarily around scope & quality criteria) creates an
environment where creativity & responding to change exist in order to best address
the customer's needs.
Controlling a stage

89
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.
Controlling a stage of a project within a programme or portfolio Consider how the
project's logs & registers should be maintained & how escalation to programme or
portfolio level is to be done in practical terms.
Controlling a stage

90
Purpose
Objective
Context
Activities

91
Purpose
The purpose of the managing product delivery process is to control the link between
the project manager & the team manager(s), by agreeing the requirements for
acceptance, execution & delivery. 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. They can be
internal or external to the customer's organization.

92
Objective
The objective of the managing product delivery process is to ensure that:
•The objective of the managing product delivery process is to ensure that:
•work on products allocated to the team is authorized & agreed.
•team managers, team members & suppliers are clear as to what is to be produced &
what is the expected effort, cost or timescales.
•the planned products are delivered to expectations & within tolerance.
•accurate progress information is provided to the project manager at an agreed
frequency to ensure that expectations are managed.

93
Context
Managing product delivery views the project from the team manager's perspective,
whereas the controlling a stage process views it from the project manager's
perspective. The team manager ensures that products are created & delivered by the
team to the project by:
• accepting & checking authorized work packages from the project manager
• ensuring that interfaces identified in the work package are maintained
• creating a team plan for the work packages being assigned)
• ensuring that the products are developed in accordance with any development
method(s) specified in the work package
• demonstrating that each product meets its quality criteria through the quality
method(s) specified in the product description;
• obtaining approval for completed products from the authorities identified in the
product description
• delivering the products to the project manager in accordance with any procedures
specified in the work package

94
Activities
The activities within the managing product delivery process are team manager
oriented & are to:
•accept a work package
•execute a work package
•deliver a work package.

95
Activities: accept a work package
The fundamental principle is that before a work package is allocated to a team, there
should be agreement between the project manager & the team manager as to what is
to be delivered. This should cover the reporting requirements, what constraints apply,
any procedures to be applied & whether the requirements of the work package are
reasonable & can be achieved.

96
•Review the work package.
•Produce a team plan to show which product(s) can be completed within the given
constraints.
•Consult with project assurance (supplier) that the team plan is viable & in
accordance with relevant supplier standards.
•Seek necessary approval for the team plan.
•Undertake a review of the risks against the team plan, & advise the project manager
of any additional or modified risks.
•Consult with project assurance as to whether any extra reviewers are required &
ensure that the quality register is updated accordingly.
•Agree to deliver the work package.

97

98
Activities: execute a work package
The work has to be executed & monitored to the requirements defined in the
authorized work package. While developing the products, the team manager should
not exceed the work package tolerances agreed with the project manager. The team
manager can only proceed with the work package or take corrective action while the
work package is forecast to be completed within the tolerances set by the project
manager. As soon as work package tolerances are forecast to be exceeded, the
team manager should raise an issue to the project manager who will then decide
upon a course of action.

99
•Manage the development of the required products
•Notify the project manager of any new issues, risks or lessons. The project manager
can then decide on an appropriate course of action.
•Take the action required by the project manager.
•Obtain approvals for completed products.
•Review & report the status of the work package to the project manager.

100

101
Activities: deliver a work package.
Just as the work package was accepted from the project manager, notification of its
completion must be returned to the project manager
•Review the quality register to verify that all the quality activities associated with the
work package are complete.
•Review the approval records to verify that all the products to be delivered by the
work package are approved.
•Update the team plan to show that the work package is complete.
•Check the work package & follow the procedure to deliver the completed products.
•Notify the project manager that the work package is complete.

102
Activities: deliver a work package.

103
context, but care should be taken to ensure the integrity of the interface to the
controlling a stage process.
As this process is where the specialist work is undertaken, work will be done using
practices which are appropriate to the type of work. It is important that monitoring &
control of specialist work is done using controls & measures which are appropriate to
that work & that the project manager should incorporate them into the appropriate
management products.
Work packages are not necessarily small in scale. All the PRINCE2 principles are as
applicable to a work package as to a project, requiring appropriate governance &
control & often needing a team manager who is skilled in project management. For
large work packages, a team manager may create a hierarchy of smaller work
packages to allocate to the team members. In this case the process for managing
product delivery should be tailored to ensure the work in any lower-level work
packages is controlled.

104
Tailoring guidelines: Tailoring products in managing product delivery
The team plan may be a subset of the stage plan, & may be informal or formal ,
depending on the context. The team plan may include components in any format
commensurate with the complexity of the work package, with views ranging from a
simple list of accountabilities, products, activities & dates to Gantt charts. The plan
may be held totally or partially within a planning tool(s). The team plan should be
developed at the same time as the stage plan, not waiting for the work package; this
will help ensure commitment & a well-integrated set of plans. In the accept a work
package activity there would need to be a confirmation that the team plan is still valid.
Checkpoint report Checkpoint reports may be informal or formal, depending on the
context. If a project manager meets with the team managers regularly, then a verbal
update, captured by the project manager in a daily log to be used to create the
highlight report, may be sufficient. Additional information, such as KPls, may be
added if it helps understanding of progress.

105
Tailoring guidelines: Tailoring roles in managing product delivery
A project manager may also undertake a team manager role. The team manager is
responsible for all activities but may be supported by team members. If a team
manager is responsible for a lower-level work package, they may report to the higher-
level team manager who is responsible for the next-higher-level work package.
Although the PRINCE2 processes define who creates, updates & approves a work
package, these accountabilities may be changed provided both the team manager &
project manager are in agreement on what the work package comprises..

106
Managing product delivery on a simple project
For simple projects, the nature of the specialist deliverables is likely to mean that
controls can be light or informal (e.g. oral checkpoint reports recorded by the project
manager in the daily log). Work packages are likely to comprise only a few specialist
products. If the project manager is also undertaking a team manager role, there may
be no need for checkpoint reports. The project manager may, however, request
individual team members to provide them. Checkpoint reports may be verbal & noted
in a daily log by the project manager.
Managing product delivery when using an agile approach
Managing product delivery handles the important interface between the project
manager & the delivery team, who will be working in an agile way. The interface
would need to be collaborative & transparent where there is a collective agreement
on what is to be produced & how this will be achieved (as opposed to a situation
where instructions are given & followed). In agile working, delivery is done iteratively.

107
Managing product delivery from a supplier perspective
From the supplier perspective, all its contracted work (to provide products) is likely to
be managed as work packages within the customer's project. Note, however, there
may be times when a supplier is providing specialist services within work packages
run by others or has part of its own work packages contracted to another supplier
(subcontractor). The controls & reporting within the managing product delivery
process should be reflected in the relevant supplier contracts to ensure the project
manager has visibility of progress & quality.
Managing product delivery on a project within a programme
Because all work packages are managed by a team manager through a project
manager, managing product delivery has no direct interface with programme
management & is therefore free of any direct impact.

108
Purpose
Objective
Context
Activities

109
Purpose
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 & acceptability of the risks.
Therefore, the process should be executed at, or close to, the end of each
management stage.

110
Objective
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 & 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 & 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.

111
Context
The managing a stage boundary process is predicated on dividing the project into
management stages. 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 & 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

112
Context

113
Activities
The activities within the managing a stage boundary process are project manager
oriented & are to:
•plan the next management stage.
•update the project plan.
•update the business case.
•report management stage end.
•produce an exception plan.

114
Activities: 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 & 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).

115
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 & suitability of the approaches & controls
•any change in the project management team or their role descriptions
•Produce the stage plan for the next management stage:
•Create (or update) configuration item records, if used, for products planned to be
produced in the next stage.
• Update the issue register & 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 & approval dates for the products.

116

117
Activities: 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, & to include forecast duration & 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.

118
Check that the current stage plan is up to date with actual progress & 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 & risk register if any new issues or risks have been

119

120
Activities: 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 & 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 do the nature & timing of the project's products.
The business case needs to reflect these changes & must be reviewed & 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 & updating the
business case in preparation for project board approval.

121
•Check whether there have been any changes to the risk appetite & risk capacity of
the organizations involved & 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 & 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.

122
•Examine & 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 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's products has changed,
which may affect the cost-benefit analysis
• the corporate, programme management or customer environment into which the project's
products 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 & issue register as necessary.

123

124
Activities: 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 & business case, & assesses the overall risk situation. This activity
should happen as close as possible to the actual end of a management stage.

125
•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.

126
Activities report management stage end
•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,
& 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
• review the issues & risks raised during the stage & any risk response actions taken . Include
a
• summary of the current aggregated risk exposure
• prepare an end stage report for the current management stage

127
Activities report management stage end
• For a stage plan:
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 &
the revised business case;
•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.

128

129
Activities: 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 & possibly
other stakeholders in order to create a viable plan. The more people involved in
planning, the more robust the plan will be.

130
•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 PIO. 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 & suitability of the project approaches & 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

131
•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 & procedures required
• update the product breakdown structure, product descriptions & 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 & risk register if any new issues or risks have been
•Update the quality register for planned quality management activities. This should
include target review & approval dates for the products

132

133
context, but care should be taken to ensure the integrity of the interfaces with the
initiating a project, controlling a stage & 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; the
PRINCE2 process model may therefore be changed to separate these two functions
into different processes

134
Tailoring guidelines: Tailoring products in managing a stage boundary
Management
Product
Stage Plan If there are only two management stages (one for initiation & the other
for delivery), the stage plan can be
included in the project plan.
Product description The project product description & 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 specia list
products. Their role may be to see that the product
descriptions are defined & reviewed rigorously enough to
enable planning to be undertaken confidently.

135
Tailoring guidelines: Tailoring products in managing a stage boundary
Management
Product
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.
Lesson 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 & dates to Gantt charts. The plan may be
held totally or partially within a planning tool(s).

136
Tailoring guidelines: Tailoring the roles in managing a stage boundary
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.

137
Managing stage boundaries on a simple project
If the project has just two management stages (the initiation stage & one delivery
stage), the scope of this process is reduced to those activities relating to managing
exceptions (if any); activities for creating the next stage plan are irrelevant as there is
no 'next stage'.
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 & sprints synchronized within each management
stage. This process provides an opportunity to assess the ongoing viability of the
project as a whole & 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 & incremental style will mean that it will be clear
how many features have been delivered, their level of quality & value added, & which
remain to be covered in later management stages.

138
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 & these need to match the stage boundaries in
the customer's project.
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 & 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..

139
Purpose
Objective
Context
Activities
Closing a project

140
Purpose
The purpose of the closing a project process is to provide a fixed point at which
acceptance of the project's product is confirmed, & to recognize that objectives set
out in the original PID have been achieved (or approved changes to the objectives
have been achieved), or that the project has nothing more to contribute.
Closing a project

141
Objective
The objective of the closing a project process is to:
•verify user acceptance of the project's products
•ensure that the host site is able to support the products when the project is
disbanded
•review the performance of the project against its baselines
•assess any benefits that have already been realized & update the benefits
management approach to include any post-project benefit reviews
•ensure that provision has been made to address all open issues & risks, with follow-
on action recommendations.
Closing a project

142
Context
One of the defining features of a PRINCE2 project is that it is finite; it has a start & an
end. If the project loses this distinctiveness, it loses some of its advantages over
purely operational management approaches.
A clear end to a project:
•is always more successful than a slow drift into use as it is a recognition by all
concerned that:
• the original objectives have been met (subject to any approved changes)
• the current project has run its course
• either the operational regime must now take over the products from this project, or the products become
• inputs into some subsequent project or into some larger programme
• the project management team can be disbanded
• project costs should no longer be incurred
•provides an opportunity to ensure that all unachieved goals & objectives are
identified so that they can be addressed in the future
•transfers ownership of the products to the customer & terminates the responsibility
of the project management team.
Closing a project

143
Context
Closure activities should be planned as part of the stage plan for the final
management stage. When closing a project, work is required to prepare input to the
project board in order to obtain its authorization to close the project. Subsequently,
the executive should also notify corporate, programme management or the customer
that the project has closed.
It is also possible that the project board may wish to trigger a premature closure of
the project under some circumstances (e.g. if the business case is no longer valid). If
the project is being brought to a premature close, this process will still need to be
executed, but may have to be tailored to the actual project situation.
Closing a project

145
Activities
The activities within the closing a project process are project-manager-oriented & are
to:
•prepare planned closure
•prepare premature closure
•hand over products
•evaluate the project
•recommend project closure.
Closing a project

146
Activities: prepare planned closure
Before closure of the project can be recommended, the project manager must ensure
that the expected results have all been achieved & delivered.
Closing a project

147
•Update the project plan with actuals from the final management stage.
•Request a product status account from project support. From the product status
account, ensure that the project's products:
• have been approved by the authorities identified in their product descriptions
• meet all the quality criteria, or are covered by approved concessions.
•Confirm that the project has delivered what is defined in the project product
description, & that the acceptance criteria have been met.
•Seek approval to give notice to corporate, programme management or the customer
that resources can be (or are about to be) released.
Closing a project

148
Closing a project

149
Activities: prepare premature closure
In some situations, the project board may have instructed the project manager to
close the project prematurely. In such circumstances, the project manager must
ensure that work in progress is not simply abandoned, but that the project salvages
anything of value created to date & checks that any gaps left by the cancellation of
the project are raised to corporate, programme management or the customer.
Closing a project

150
•Update the issue register (and, if necessary, the issue report) to record the
premature closure request.
•Update the project plan with actuals from the final management stage.
•Request a product status account from project support. From this, determine which
of the project's products:
• have been approved by the authorities identified in their product descriptions
• are currently in development (and which of those need to be completed)
• are covered by approved concessions
• have yet to be started
• need to be made safe
• may be useful to other projects.
•Agree the means for recovering products that have been completed or are in
progress.
•Seek approval to give notice to corporate, programme management or the customer
that resources can be (or are about to be) released early.
Closing a project

151
Closing a project

152
Activities: hand over products
The project's products must be passed to an operational & maintenance environment
prior to the project being closed. This may happen as a single release at the end of
the project, or the project approach may include phased delivery where products are
handed over in a number of releases. In the case of a premature closure, there may
be some products that have been approved but not yet handed over and, depending
on the project board guidance, the ownership of some or all of those products may
need to be transferred to the customer.
When handing over products, the benefits management approach may need to be
updated to include the post-project benefits review(s) of the performance of the
project's products in operational use. Such benefits reviews may identify whether
there have been any side-effects (beneficial or adverse) that could provide useful
lessons for other projects.
There may be multiple handovers throughout the project lifecycle. It is not a project
activity to undertake benefits reviews post-project, only to plan for such benefits
reviews to occur. If the project is part of a programme, then the post-project benefits
reviews need to be covered by the programme's benefits management activities.
Closing a project

153
•In consultation with the project management team, prepare follow-on action
recommendations for the project's products to include any uncompleted work, issues
& risks. There could be separate follow-on action recommendations for each product
or distinct user group (e.g. human resources, finance, operations).
•Check that the benefits management approach includes post-project activities to
confirm benefits that cannot be measured until after the project's products have been
in operational use for some time (e.g. reliability requirements).
•Examine the change control approach to confirm how products are to be handed
over to those who will maintain them in their operational life:
• confirm that the correct operational & maintenance environment is in place
• consider the early life-support requirements of each product being handed over because the early
life of a product is often the period of peak demand on the support organization
• when a product requires a lot of potentially expensive support & maintenance, ensure that a
suitable service agreement or contract has been drawn up between the operations &
maintenance organizations & the end-users. Such an agreement should be included as a product
to be developed by the project
Closing a project

154
Closing a project

155
Activities: evaluate the project
Successful organizations learn from their experiences with projects. When evaluating
the project, the objective is to assess how successful or unsuccessful the project has
been. It may also be possible to improve the estimation for future projects by
analysing the estimates & actual progress metrics for this project.
Closing a project

156
•Review the project's original intent as agreed in the initiation stage & defined by the
PIO, baselined at that time.
•Review the approved changes as defined by the current version of the components
of the PIO.
•In consultation with the project management team, prepare an end project report to
include:
• the project manager's summary of how the project performed
• an assessment of the results of the project against the expected benefits in the business case
• a review of how the project performed against its planned targets & tolerances
• a review of team performance
• a review of the project's products
• if necessary, the documented reasons why a project was brought to a premature close.
•In consultation with the project management team, review the lessons log to identify
lessons that could be applied to future projects & incorporate them into the end
project report.
Closing a project

157
Closing a project

158
Activities: recommend project closure.
After the project manager has confirmed that the project can be closed, a closure
recommendation should be raised to the project board.
Closing a project

159
•Use the communication management approach to identify any organization or
interested party who needs to know that the project is closing. Consider also
communication activities for public relations & marketing opportunities at this point.
•Close the project's issue register, risk register, quality register, daily log & lessons
log.
•Make sure that all project information is secured & archived (in accordance with the
change control approach) in order to permit any future audit of the project
management team's decisions, actions & performance.
•Prepare & send a draft project closure notification for review by the project board,
stating that the project has closed.
Closing a project

160
Closing a project

161
context, but care should be taken to ensure the integrity of the interface to the
directing a project & controlling a stage processes. If the final stage(s) of the project
includes initial operation of the outputs, the hand over products activity may not be
undertaken in the project's final management stage as part of closing the project, but
may happen within a number of previous management stages. Closing the project
would then only require confirmation that all handovers have been completed.
Closing a project

162
Tailoring guidelines: Tailoring products in closing a project
Closing a project
Management
Product
End project report Any element of the composition may be provided in a separate
document or information source, which
should be cross-referenced.
The composition may be adapted to suit the readership; for example,
confidential elements, such as
the review of the business case or team performance, may be
included in separate documents
Lesson log Lessons from the log or lessons report (if one has been created) are
usually included in the end project
report but may be presented in a separate document.

163
Tailoring guidelines: Tailoring roles in closing a project
in this process, but may delegate work to others provided overall responsibility is
retained.
The checking that post-project benefits reviews are planned to take place may be
undertaken by the senior user in the hand over products activity
Closing a project

164
Tailoring guidelines: common situations
Closing a simple project
All activities may happen in a very short timescale; for example, handover, evaluation
& closure approval (from directing a project) could all happen at a single meeting.
Closure activities do not need to be formally documented, with a daily log entry,
minutes of a meeting or email sufficing, provided it is clear to all stakeholders & the
project management team that the project is closed & what the follow-on actions are.
Closing a project when using are agile approach
When using agile, project closure is still likely to be a formal event. However, most of
the information is already known & most of the work is already done due to the
iterative & incremental nature of the agile way of working. Examples of this would be
that benefits may already be being realized, most of the project's products are in
operational use & documentation is almost complete & just needs to be finalized. In
addition, many lessons will already have been identified during retrospectives at the
end of each sprint.
Closing a project

165
Closing a project from a supplier perspective
It should be decided when the project is completed from a supplier perspective. For
example, this may be when the work is completed, after any maintenance or warranty
period has elapsed, or when the contract is fulfilled.
Closing a project within a programme
All the guidance provided above is applicable to a project within a programme, except
that any decisions & the plan for the benefits reviews will be made in the context of
the programme, whether closure is premature or is on completion of the project.
Closing a project

166
Tailoring PRINCE2 for an organization
Embedding PRINCE2 in the organization
Considerations for adoption

167
Tailoring PRINCE2 for an organization
Creating an organization's PRINCE2-based project management method
• understanding the drivers & objectives for adopting Prince2
• deciding who to involve
• Using maturity models
• Pulling elements of PRINCE2 together
• project lifecycles
• managing the method
Creating tailoring rules & guidelines

168
Understanding the drivers & objectives for adopting Prince2
Before creating a project management method, it must be understood why an
organization wants to do this. By understanding the drivers and objectives, it is more
likely that a method will be created that meets the needs of the organization
Deciding who to involve
The people involved in the development of a new method should have the right skills
and experience; they may be in-house experts, consultants or a mix. The method
they create must be acceptable to the users (stakeholders). A way of moving to a
common method within an organization is to collect together some experienced and
respected project managers to compare the way that they do things now, and ask
them to agree an approach that appears to be acceptable to all; use recognized
experts to facilitate discussions on contentious issues and, if necessary, recommend
a solution. This will not only ensure that collective experience is harnessed but will
also promote buy-in.
Using maturity models
Pulling elements of PRINCE2 together

169
Using maturity models
The increase in business performance through the effective use of project
management methods across organizations has been demonstrated through the use
of maturity assessments, which measure an organization’s capability to manage
projects, programmes and/or portfolios. The higher the maturity an organization
attains, the more effective and efficient it is in business terms.
Pulling elements of PRINCE2 together
Consistent terminology is important, as using words in a consistent way helps
communication and understanding. The organization’s method should, as far as is
realistic, reflect the terminology used in the organization. Problems will occur when
different parts of the business use different terminology, neither of which may be
wrong. For this reason, it is helpful to agree, in advance, the definition of key project
management terms
Project lifecycles
Managing the method

170
Project lifecycles
Although PRINCE2 does not prescribe the use of any particular project lifecycle, it
does require that one is used. Rather than each project manager designing their own,
consider including one in the project management method, describing the purpose of
each management stage and linking back to the PRINCE2 processes and themes.
Standardizing the project lifecycle gives project managers a basis from which to tailor
their own. It also enables the organization to have an overview of the progress of its
portfolio of projects.
Managing the method
After a method has been created, it needs to be managed and maintained. The
method should therefore include guide(s), procedures or processes describing how it
is managed, together with associated roles and product descriptions. The roles
should include one to manage the overall architecture of the method, ensuring that
the process model and its component parts work as a whole. Changing one
component may impact other components, and so change control should be
considered as part of this.

171
Tailoring PRINCE2 for an organization: Creating tailoring rules & guidelines
As PRINCE2 has a tailoring principle, any method derived from it should also allow
tailoring. This means that the method should include tailoring rules and guidelines.
This may be covered in a few pages of text or may involve a lot of detail, describing if
and how each element of the method could be tailored.
As PRINCE2 can be used regardless of the complexity or scale of the project,
organizations may consider rating their projects by complexity and providing guidance
on how each category should be tailored.
The aim is to help project practitioners decide what is ‘just enough’ project
management in order to ensure project success.
The greater the complexity of the project, the more information that is generated. A
project manager should ensure that the means of storing and distributing information
is efficient and secure. For simpler projects, a log book and wall display may be
sufficient, but for more complex projects, especially with distributed teams,
information systems will need to be developed and rolled out.

172
Tailoring PRINCE2 for an organization: Examples of how organizations have
tailored prince2

173
Management of change
Changing the way people work
Design of the future state
Consistently deploying the method
Ensure consistency across all impacted parts of the organization
Big bang approach
Incremental approach
Track progress of the change
Building & sustaining maturity

174
Management of change: Changing the way people work
The introduction of an organization's project management method involves changing
the way that people work, so that the outcome can be realized, leading to a higher
project success & enhanced business performance.
Current approaches to change management combine the psychological &
engineering views of the world to create repeatable change methods, drawing on a
wide range of tools & techniques. The application of different change methods has
implications for the way organizations & their leaders regard change, the way they
manage change & even the effectiveness of any change initiatives. At the heart of
most change models is gaining the support of those who are required to change their
ways of working. To gain stakeholder support, change management approaches
should not just involve training, but may also include coaching, mentoring,
stakeholder engagement, marketing & communications activities to embed a real
understanding of the need for the change & the resulting benefits. Change is as much
about managing people's expectations & perceptions as managing facts.

175
Management of change: Design of the future state
The design of the future state of a project management method should reflect the
vision for how project management will work after the method is embedded. It should
include the roles, processes, tools & behaviours relating to using the method itself &
to any supporting organizational units. Projects should be perceived as part of the
organization & therefore any processes, roles or approaches should align with those
used in the rest of an organization. As project management is a form of governance it
should explicitly link with the overall governance of the organization; embedding
project management strengthens corporate governance. Common areas where this is
apparent include the allocation of resources, the authorization of funding for projects,
procurement of goods & services, audit, accounting & human resources practices.

176
Consistently deploying the method
Ensure consistency across all impacted parts of the organization
The deployment of project management throughout an organization involves the roll-
out of the project management method & supporting tools, together with the change
management activities to promote the use of the method
Big bang approach
In the 'big bang' approach, the project management method & its supporting
elements are activated for use on the same day; all plans focus on this go-live date.
Such an approach may be suitable in a small or new organization, but the actual go-
live date would be constrained by the longest lead element of the project and
Incremental approach
In most cases an incremental approach to rolling out the project management
method & its supporting capabilities would be the most flexible & practical. By taking
this approach, early benefits can be realized & the amount of change that users have
to cope with at any one time reduced. It enables roll-out to be progressive, say
geographically, so that deployment resources are not overstretched

177
Building & sustaining maturity
If practitioners do not continue to use a project management method after the initial
deployment, the effort & cost of creating it are wasted. A method needs ongoing
active management if it is to benefit the business & help to continually improve
business performance.
The creation of a method should not be an objective in its own right but just one
component in a mix of capabilities aimed at improving business performance. Using a
method requires people to be skilled & competent at their jobs; a method simply
brings consistency in approach, where consistency adds value. The method should
remain relevant to its users & so direct engagement should be encouraged through
feedback & stakeholder involvement.
Tracking usage of the method can be hard; however, as most methods tend to be
published on an organization's intranet site, a simple 'click' count combined with
analytics can provide a pattern of usage. Initially the use of the site should increase,
but unless momentum is maintained, usage may drop off Tracking the quantity of
feedback & any resulting changes to the project management method is indicative of
user engagement

Prince2017 part 2

More Related Content

What's hot (20)

Similar to Prince2017 part 2 (20)

More from Robert Edward Pinnington (6)

Recently uploaded (20)

Prince2017 part 2