Management products P2A

1. Benefits management approach

Benefits are the reason projects are undertaken. They represent what the project is trying to
achieve. Projects produce a product or service, but that product is trying to achieve some form of
benefit for the parent organization. If the product is great, but the benefits are not realized,
the project is still a failure. The benefits management approach must state how the benefits to the
parent organization will be achieved. It describes how to measure those benefits, and what
management plans are necessary to achieve them.
2. Business case
The business case identifies the underlying business fundamentals which gave rise to the project.
It identifies the expected return on investment analysis, reasons for undertaking the project, and
expected benefits. It includes the various business scenarios and their financial analysis.
3. Change control approach
This approach is produced during project initiation and identifies the policies and procedures which
apply to project changes. These changes can be budget, schedule, scope, or any other item
within the project plan. It details the reports that will be produced when project changes occur,
and who will approve these reports.
4. Checkpoint report
This report is produced by the team manager, who is a technical manager tasked with the
production of some or all of the project deliverables, and its primary audience is the project
manager. The team manager updates the project manager at intervals necessary to ensure
project progress. Checkpoint reports can be anything from verbal to formal reports.
5. Communication management approach
This approach states and communication strategy of the project to its stakeholders. Stakeholders
are anyone who has an interest in the project, positive or negative, and their communication needs
are usually vastly different from each other. This communication management approach defines
the type of communication, frequency, mode of delivery, intended audience, and any other item
that is necessary to establish a strong communications management foundation for the project.
6. Configuration item record
In order to avoid confusion and manage the development of new products or services, projects
need a tracking mechanism for the product they are creating. The version number, current status,
location, responsible person, etc. are logged within the configuration item record.
7. Daily log
The project manager records informal items, action items, or other issues not tracked by the formal
logs. It can act as a project diary. It can also act as an issue and risk register if those have not
been set up.
8. End project report
This report is used to formally close the project. It records lessons learned, ongoing product
usage or maintenance information, final details and final cost information.
9. End stage report
This report is produced by the project manager to obtain formal approval from the project board to
proceed to the next stage. It contains a review of the project’s business case, a review of the
stage that is finishing, and any issues and major risks. The quality control measurements of the
deliverables and approval records are analyzed. The project manager’s forecast for the next
management stage based on the experience of the current stage is also summarized.

10. Exception report

The Exception report is produced when a management stage exceeds its tolerances in a certain
area. The report identifies the available options to remedy the problem and recommends one of
the options to the project board. Also, the implications for the business case are analyzed. Once
the project experiences an exception, an exception plan must be prepared which, once approved
by the project board, replaces the stage plan for that management stage.
11. Highlight report
A highlight report is produced by the project manager for the purpose of updating the project board
on the project status. The project board defines the intervals of highlight report preparation during
the project initiation process. The report covers progress on budget, schedule, scope, risks, and
benefits. It summarizes the previous reporting period, and forecasts the next reporting period. It
also identifies any issues that have arisen and how they have/will be dealt with.
12. Issue register
Any problem that occurs, whether or not it puts the project out of tolerance, is an issue. Issues are
logged and tracked to ensure that they are dealt with promptly and decisively. The issue register
can be a powerful record of what the project had to deal with during its life cycle, and provide
lessons learned that improve future projects.
13. Issue report
Not all issues require an issue report, but when formal changes need to be made to solve the
issue, a formal issue report is drawn up which contains the description, impact assessment and
recommendations for change. The issue report is a living document that is updated as the issue is
handled and assessments and/or decisions are made.
14. Lessons log
This log captures any lessons learned that can be applied to the remainder of the project, or future
projects within the organization. It is updated whenever lessons are learned and creates a
powerful way to comply with Principle #2, Learn from Experience.
15. Lessons report
When lessons learned are complex, or require action relatively soon, a lessons report supports an
entry in the lessons log and can be used to communicate actions items for improvement to the
project team, stakeholders, or the parent organization.
16. Plan (covers project plans, stage plans, exception plans, and optionally, team plans)
The project plan contains all of the information required to communicate how the project intends to
produce its products or services. It contains schedules, budgets, scope statements, benefits
analysis, risk analysis, and delivery approaches. Project plans come on three different levels: The
main project plan, a stage plan, and a team plan.
The first two are produced by the project manager, and the third is produced by the team
manager. The project plan and stage plans are quite similar in content, except that the stage plan
deals with a limited part of the project.The plans identify the work packages (work breakdown
structure) that is required to produce the deliverables. These tasks are then analyzed to produce
a schedule and budget. The project control methods are also identified, that is, procedures to be
employed to ensure the project remains on budget, on schedule, and within the tolerances
specified by the project board.
17. Product description

All projects produce some sort of product which is

delivered to a permanent owner. The output of the project can also be a service, such as a project
to provide a training course. Regardless of the final outcome, the product description describes
the product, its purpose, composition, format, quality criteria, and any other item relevant to its
production. The more detailed the product description, the better the project team will be at nailing
it the first time.
18. Product status account
The product status account describes the current status of the product. It can be used to
communicate items like production information, testing results, current cost status, etc.
19. Project brief
The project brief explains what the project needs to achieve. It includes the business case, project
objectives, scope and scope exclusions, tolerances, and any other information of relevance. It is
produced during the Starting up a Project process, hence it precedes even the project planning. It
is used by the parent organization to set up the project for success.
20. Project initiation documentation (PID)
The PID is probably the most important document in the PRINCE2 system. It provides the project
planning. It includes the project stage breakdown, schedule, budget, quality criteria, and any other
item required to carry out the project. The PID is a living document that is updated regularly and
always provides a snapshot of the project plan. It always reflects the current project status and
pathway to the finish. However, the original PID is preserved in order to assess the overall project
performance. The PID contains the following parts:
 Project definition
 Project approach
 Business case
 Project management team structure
 Role descriptions
 Quality management approach
 Change control approach
 Risk management approach
 Communication management approach
 Project plan
 Project controls
 Tailoring of PRINCE2
21. Project product description
Since all projects produce a unique product or service, the description of what the project will
produce is a central component. Sometimes it is clear to everyone what is being produced, but in
many situations the product description is an important item which must be reviewed regularly to
keep everyone focused on the end result. The quality expectations should be discussed and
analyzed in enough detail to ensure that the final product is acceptable. The acceptability criteria
should be agreed upon and the stated in the product description to ensure that the goalposts don’t
move mid-project.
22. Quality management approach
This document describes what the quality standards are, how they will be achieved, and how
quality will be measured. Quality is inherent in every project. The client or customer is expecting
a certain level of quality, even though they might not say it. Oftentimes the quality expectations of
customer and the project team are different – usually it is the customer that expects a Mercedes-
Benz when the project team was expecting to deliver a Chevy.
23. Quality register
In order to ensure adequate project quality, the Quality Register is used to track quality activities.
Most project require quality control (QC) measurements of some sort, which are measurements
taken at the tail end of the production facility to determine how many widgets are out of spec.
24. Risk management approach
This approach itemizes the risk management activities that will take place. The risk identification
and analysis procedures, probability and severity indices, and risk responses are detailed. Roles
and responsibilities for risk response plans are specified and risk tolerances for the organization
are analyzed.
25. Risk register
The Risk Register provides an itemization of risks that might affect the project’s success. Each
risk is analyzed according to its primary factors – probability and severity. The most important
risks are developed into risk response plans that can be drawn upon when they occur. The Risk
Register is a living document that is re-evaluated at the end of each stage, or as decided by the
project management team in the PID.
26. Work package
The work package is the most basic unit of project work. It is a project task. Work packages are
controlled by the team manager, who reports to the project manager. A collection of work
packages make up a management stage. Work packages require measurement of tolerances, for
example scope and budget tolerances, to ensure they do not deviate outside the project plan. Any
issues that arise must be logged in the Issue Log, and if necessary an Issue Report is escalated
up to the project board.