PRINCE2 Notes: The Following Are Study Notes From PRINCE2 Manual Published by The UK Office of Government Commerce
PRINCE2 Notes: The Following Are Study Notes From PRINCE2 Manual Published by The UK Office of Government Commerce
PRINCE2 Notes: The Following Are Study Notes From PRINCE2 Manual Published by The UK Office of Government Commerce
The following are study notes from PRINCE2 manual published by the UK
Office of Government Commerce.
Introduction
The PRINCE2 method includes (a) principles, (b) themes, (c) processes and
(d) tailoring. There are only two specific techniques detailed; the product-
based planning technique and quality review technique.
Principles
A PRINCE2 project has defined and agreed roles and responsibilities. All
projects have the following primary stakeholders; business sponsors, users,
and suppliers. Business sponsors ensure the investment provides value for
money. Users gain the intended benefits and feel the pain. Suppliers, internal
and external, provide the resources.
A PRINCE2 project has agreed tolerances for its aspects. If these tolerances
establish limits of delegated authority. If they are breached the next higher
level must manage the exception. PRINCE2 enables appropriate governance
by defining distinct responsibilities for directing, managing, and delivering
the project.
The three basic business options concerning investment always include (a)
do nothing, (b) do the minimal (e.g., a workaround), (c) do something.
The Business Case should list each benefit that it is claimed would result
from the project's outcome. This can be financial and non-financial, but must
be aligned to corporate strategy, mapped to outcomes and outputs,
quantified (with tolerance), measurable, and assigned.
Organisation Theme
PRINCE2 does not define management jobs - it defines roles. This includes
the three primary categories of stakeholder which are included on the Project
Board; Business, User and Supplier interests. The Business is interested in
value for money, the User in desired outputs, and the Supplier in producing
the project products. The customer is usually interpreted as a collective term
for Business and User roles. Sometimes the Executive (Business) can be
combined with the Senior User.
PRINCE2 separates the direction and management of the project from the
delivery of the outputs. The project management structure has four levels, of
which the bottom three represent the project team. The top level is the
corporate or programme management. The Project Board gives direction, the
Project Board gives management, the Team Manager delivers.
The Executive is ultimately accountable for the project's success and the key
decision maker. The Executive ensure that project gives value for money and
is responsible for the Business Case. The Senior User represents those who
will use the project (including operations and maintenance). The Senior
Supplier is accountable for the quality of products delivered and is
responsible for the technical integrity of the product.
In PRINCE2 the Project Manager's role should not be shared. The Project
Manager managers Team Managers and Project Support, and is responsible
for liaison with Project Assurance and the Project Board. The Team Manager's
primary responsibility is to ensure production. PRINCE2 uses Work Packages
to allocate work to Team Managers or team members.
Quality Theme
The theme of Quality defines the means by which a projects verifies that
products are fit for purpose. Quality Systems and Quality Assurance exist on
the Corporate level and should be differentiated from Quality Planning and
Quality Control, on the Project level.
In PRINCE2 Quality is defined as the totality of features in a product,
process, person, service, or system. The scope of a plan is the sum total of
its products, defined by a product breakdown structure.
Project Assurance is undertaken from within the project and assures that the
project is being conducted properly with regard to internal rules. Quality
Assurance is the responsibility of the corporate or programme management
is external to the project. It assurances the the project complies to corporate
standards and legislation.
Plans Theme
Plans are the backbone of the management information system required for
any project. They must be kept in line with the Business Case at all times.
PRINCE2 recommends three levels of plan to suit the needs of the different
levels of management. Outside of the project there may be a corporate or
programme plan. The Project Plan provides the Business Case, with Project
costs and timescales as a baseline. The Stage plan is similar to the Project
Plan but with adequate detail for day-to-day control for the Project Manager.
Team plans are produced by a Team Manager to facilitate Work Packages.
They are optional.
Exception Plans are prepared for the appropriate management level to show
the actions required to recover from the effects of tolerance deviation.
A flow diagram needs to be created that identifies and defines the sequence
in which the products of the plan will be developed and any dependencies
between them. Dependencies are internal or external. An external
dependency includes the delivery of a product from another project.
Risk Themes
Project Support will maintain the Risk Register on behalf of the Project
Manager.
Change Themes
The Change theme identifies, assesses and controls changes to the baseline.
The baseline should use a form of version control in documentation. The
process to manage changes and issues is the Configuration Management
Strategy.
Issues consist of Requests for Change (funded from the Change Budget),
Off-Specifications aka stuff-ups (funded from Tolerances), and
Problem/Concerns, which require approval from the Project Board.
Tolerances should not be used to fund Requests for Change!
The following management products are used to establish and maintain the
project's controls for issues, changes, and configuration management: (a)
configuration management strategy, (b) configuration item records, (c)
product status accounts, (d) daily log, (e) issue register, (f) issue reports.
Progress Theme
The Work Package and report back to the Project Manager is via Checkpoint
Reports. There is one Checkpoint Report per Work Package.
If the forecast is project tolerances will be exceeded, the Project Board has
the authority to manage the project and must refer the matter to corporate
or programme management for a decision.
Processes
The Project Board reviews the brief and decided whether to initiate the
project. The initiation stage culminates in the production of a Project
Initiation Document. The Project Board delegates day-to-day control to the
Project Manager on a stage-by-stage basis. The Project Manager ensures
that a set of project records are maintained to assist with project control.
The Team Managers execute the Work Packages and keep the Project
Manager appraised of progress via Checkpoint Reports. During the final
stage, once the Project Manager has gained approval for all of the Project's
products, it is time to decommission the project.
The purpose of the directing a project process is to enable the Project Board
to be accountable for the project's success whilst delegating day-to-day
management to the project manager. The Project Board manages by
exception. It monitors via reports through a small a number of decision
points. The Project Board is responsible for ensuring there is continued
business justification.
Within the directing a project process, the Project Board will authorise
initiation, authorise the project, authorise a stage or exception plan, give ad-
hoc direction, and authorise project closure. Initiation is triggered by a
request from the Project Manager for authorisation to deliver the project. Ad-
hoc direction may occur as a response to reports e.g., Highlight Report
(time-driven within a stage), Exception Report, Issues Report.
Authorising closure of the project is the last activity undertaken by the
Project Board, prior to its own disbandment, and may require endorsement
from corporate or programme management.
During this process the Project Manager will create a suite of management
products required for the level of control specified by the Board. This will
include the Risk Management Strategy, the Configuration Management
Strategy, the Quality Management Strategy, the Communications
Management Strategy, the project controls, the Project Plan, a refined
Business Case, and assembling the Project Initiation Documentation.
The refined Business Case will include a Benefits Review Plan. The Business
Case will be part of the Project Initiation Documentation.
The activities to establish the strategies for the project may be executed in
parallel, but it is recommended that the Communications Management
Strategy is completed last as it will need to include any communications
required of the other strategies.
The purpose of the controlling a stage process is to assign and monitor work,
deal with issues, report progress to the Board, and take corrective actions to
ensure that the stage remains within tolerance levels.
The controlling a stage processes is first used after the Board authorises the
Project. Work Packages are used to define and control the work being done,
and sets tolerances for the Team Managers. There must be a level of
autonomy within the project teams.
Activities include the authorisation, reviewing work package status, and
receiving completed work packages, reviewing stage status, reporting
highlights to the Board, examination of issues and risks, escalation of issues
and risks and taking corrective action.
The purpose of the managing product delivery process is to control the link
between the Project Manager and the Team Managers by placing formal
requirements on accepting, executing, and delivering project work.
The Team Manager agrees works on products allocated to the team and is
authorised to carry out the tasks by the Project Manager. Accurate progress
information is provided to the Project Manager via Checkpoint Reports.
The purpose of the managing a stage boundary process is for the Board to
review the current stage, approve the next stage, review the updated project
plan, confirm business justification and acceptance of risks. The Board must
assure that all products in the current stage plan have been completed and
approved. For exceptions, the Project Manager must prepare an Exception
Plan and seek approval from the Board for the Exception Plan.
The activities within the managing a stage boundary process include planning
the next stage, updating the project plan, updating the business case,
reporting a stage end, and producing exception plans.
Documentation for the Managing A Stage Boundary process include the
Project Initiation Document (U) (Project Plan, Business Case), Stage
Plan/Exception Plan (C) (Product Descriptions)
The purpose of the closing a project process is to provide a fixed point where
acceptance of the project product has been confirmed and that the objectives
in the Project Initiation Document have been achieved.
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 the work in progress is not simply abandoned, but
that the project salvages anything of value created to date and checks that
any gaps left by the cancellation of the project are raised to corporate or
programme management.
Documentation in the Closing A Project process include the Project Plan (U),
Product Status Account (C), Issues Register (U), Additional Work Estimates
(C), End Project Report (C), Configuration Item Records (U), Benefits Review
Plan (U). Follow-On Recommendations (C, U), Lessons Report (C),
Acceptance Records (formalises that the project has met its agreed
acceptance criteria).