PRINCE2 is derived from an earlier method called PROMPTII,
and from PRINCE project management method, which was initially developed in
1989 by the Central Computer and Telecommunications Agency (CCTA) as a UK
Government standard for information systems (IT) project management;
however, it soon became regularly applied outside the purely IT environment.
PRINCE2 was released in 1996 as a generic project management method.
Starting up a project
In this process the project team is appointed and a
project brief (describing, in outline, what the project is attempting to
achieve and the business justification for doing so) is prepared. In
addition the overall approach to be taken is decided and the next stage
of the project is planned. Once this work is done, the project board is
asked to authorize the next stage, that of initiating the project.
Key activities include: appointing an executive and a
project manager; designing and appointing a project management team;
preparing a project brief; defining the project approach; and planning
the next stage (initiation).
Initiating a project
This process builds on the work of the start up
process, and the project brief is augmented to form a Business case. The
approach taken to ensure quality on the project is agreed together with
the overall approach to controlling the project itself (project
controls). Project files are also created as is an overall plan for the
project. A plan for the next stage of the project is also created. The
resultant information can be put before the project board for them to
authorize the project itself.
Key activities include: planning quality; planning a
project; refining the business case and risks; setting up project
controls; setting up project files; and assembling a Project Initiation
Document.
Directing a project
This process dictates how the Project Board (which
comprises such roles as the executive sponsor or project sponsor) should
control the overall project. As mentioned above, the project board can
authorise an initiation stage and can also authorize a project.
Directing a Project also dictates how the project board should authorize
a stage plan, including any stage plan that replaces an existing stage
plan due to slippage or other unforeseen circumstances. Also covered is
the way in which the board can give ad hoc direction to a project and
the way in which a project should be closed down.
Key activities include: authorising initiation;
authorising a project; authorising a stage or exception plan; giving
ad-hoc direction; and confirming project closure.
Controlling a stage
PRINCE2 suggests that projects should be broken down
into stages and these sub-processes dictate how each individual stage
should be controlled. Most fundamentally this includes the way in which
work packages are authorised and received. It also specifies the way in
which progress should be monitored and how the highlights of the
progress should be reported to the project board. A means for capturing
and assessing project issues is suggested together with the way in which
corrective action should be taken. It also lays down the method by which
certain project issues should be escalated to the project board.
Key activities include: authorising work package;
assessing progress; capturing and examining project issues; reviewing
stage status; reporting highlights; taking corrective action; escalating
project issues; and receiving a completed work package.
Managing stage boundaries Main article: Managing stage
boundaries
The Controlling a Stage process dictates what should
be done within a stage, Managing Stage Boundaries (SB) dictates what
should be done towards the end of a stage. Most obviously, the next
stage should be planned and the overall project plan, risk log and
business case amended as necessary. The process also covers what should
be done for a stage that has gone outside its tolerance levels. Finally,
the process dictates how the end of the stage should be reported.
Key activities include: planning a stage; updating a
project plan; updating a project business case; updating the risk log;
reporting stage end; and producing an exception plan.
Managing product delivery
The Managing product delivery process has the purpose
of controlling the link between the Project Manager and the Team
Manager(s) by placing formal requirements on accepting, executing and
delivering project work. The Objectives of the Managing Product Delivery
process are: - To ensure that work on products allocated to the team is
authorised and agreed, - Team Manager(s), team members and suppliers are
clear as to what is to be produced and what is the expected effort, cost
and timescales, - The planned products are delivered to expectations and
within tolerance, - Accurate progress information is provided to the
Project Manager at an agreed frequency to ensure that expectations are
managed.
The key activities are: Accept a work package, execute
a work package and deliver a work package.
Closing a project
This covers the things that should be done at the end
of a project. The project should be formally de-commissioned (and
resources freed up for allocation to other activities), follow on
actions should be identified and the project itself be formally
evaluated.
Key activities include: decommissioning a project;
identifying follow-on actions; and project evaluation review.
Overview of the
method 