PRINCE2™ FLASH CARD SUMMARIES
The Perfect Way To Grasp The Key Learning Elements of PRINCE2™
© Copyright David Geoffrey Litten First Edition 2008 Copyright of text and diagrams © 2008, David Geoffrey Litten. Published by Casablanca Publishing. All rights reserved The right of David Geoffrey Litten to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988 All PDF files and Video’s have been encoded with a unique tracking identifier. Anyone found engaging in illegal copying will be prosecuted under the full extent of the law. PRINCE2TM is a trade Mark of the Office of Government Commerce. ® PRINCE is a Registered Trade Mark and a Registered Community Trade Mark of the Office of Government Commerce and is registered in the U.S. Patent and Trade Mark Office No part of this publication and the accompanying Video Set may be reproduced, stored in a retrieval system or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise without the prior written permission of the publisher Notice No responsibility is assumed by the publisher for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions or ideas contained in the material herein. PROCESS
The Project Processes
The 8 Processes may be considered as a set of "Toolkits" to be used WHEN needed.
Some processes are normally only used only once during a project:
Starting Up a Project
Initiating a Project
Closing a Project
Other processes are used on a regular basis WHEN needed:
Controlling a Stage
Managing Product Delivery
Managing Stages Boundaries
One process is used continuously from the beginning of the project until the close of the project:
Directing a Project
Finally,
Planning
Within PRINCE2, all plans are documents. And so one process is designed to be used whenever a Project,
Stage, Team, or Exception Plan is to be created (or possibly updated).
PROCESS
Starting up a project (SU)
This is the pre-project preparation process, consisting of a high level analysis of the project.
It is also where the project management team are designed and appointed.
The information gathered and created in this process is put before the project board, which is where they
meet for the first time, so that they can make a decision whether or not to start the project.
They should agree that the project makes sense to do, and if so, agreed to invest in the creation of the
Project Initiation Document.
The project mandate triggers starting up a project, and ensures that a business requirement exists.
SU must answer “do we have and viable and worthwhile project"
SU is designed to ensure that the pre-requisites for the initiation stage are in place.
SU provides management products that provide basic information such that the project board can make an
informed choice whether or not to invest in the initiation stage and the creation of the Project Initiation
Document.
SU creates the plan for the initiation stage which covers the time and resources for the creation of the
project initiation document, and the time and resources to prepare and plan for the second stage.
PROCESS
Initiating a Project (IP)
This process is used during the first stage - the Initiation Stage, and assembles the project initiation
document (PID). The PID defines in as much detail as is possible at this time, the definition of the project
including creation of the project plan and business case and how the project will be controlled.
Other key documents include the project quality plan, the configuration management plan, the
communication plan, and implementing the controls. In addition the remaining logs are created: the
quality log, the Lessons Learned Log, and the Issue Log (which is also used to log changes).
This information will be presented to the project board, who meet for the second time to authorise the
project. It is not until the second stage that any specialist products are created.
The PID set out WHAT the project is intended to achieve, WHY it is needed, HOW the outcome is to be
achieved WHEN activities are to happen, and what (WHO) people's responsibilities are. Responsibility for
the creation of the PID is the project manager’s assisted many others.
The project is split into a number of management stages; the first stage is called the Initiation Stage.
The minimum number of stages is two. A stage is defined as “partitions of the project with management
decision points", and at the end of each stage, the project board must approve the next stage plan
including the resources required before authorising the project manager to control and manage that stage.
Once the PID is signed off by the project board it is they that now own the project
The PID will be used as a "baseline" against which to monitor and manage control and report throughout
the project. Parts of the PID will be updated at the end of each stage to reflect the latest progress and
understanding.
It is important that the PID contains a viable Business Case demonstrating that the benefits to be realised
worth the time, effort, cost and risks
PROCESS
Directing a Project (DP)
This process is used by the project Board who represents the business, users and suppliers. They make all
the key decisions and must have the authority to exercise overall control and commit resources during the
project life cycle.
The project board manages by exception, monitors and via reports and controls through a number of
decision points.
Manage By Exception. This is done by releasing the project to the project manager one stage at a time,
and setting a tolerance band that the stage must complete within. The project board are kept informed of
stage status by regular highlight reports from the project manager.
If the stage is forecast to exceed tolerance, then the project manager brings this to the project board's
attention by issuing an Exception Report. The project board will then decide I to prematurely close the
project, or to request an Exception Plan, which if authorised by them, will replace the existing stage plan
that would no longer finish within tolerance
The project board meets to authorise the initiation stage, then again to authorise the project by signing off
the PID. After this they will meet at the end of each stage (End Stage Assessment), to agree or not that
the project should continue. At the end of the project, the project board meets for a final time to confirm
that the project should be closed.
The project board is also responsible for communicating with external interested parties.
The sub-process "Giving Ad-Hoc Direction" is used as a communication path both within, and external to
the project. All other sub-processes are "event-driven" in that the project board brought together to
provide direction and authorisation as and when needed.
PROCESS
Managing Stage Boundaries (SB)
This process is only used for two purposes: preparation for an End Stage Assessment leading to approval
or otherwise of the next stage plan, or... preparation for an Exception Assessment - leading to approval or
otherwise, of an Exception Plan.
The project manager will do most of the work in preparing for the end stage assessment - or an exception
assessment if needed.
But the Project Manager will be assisted by others such as project support, Project Assurance, the
Configuration Librarian, and even the specialist team who may have been involved in the creation of the
Team Plan, as well as contributing to creation of the Stage Plan.
This process includes updating of the Project Plan, the Business Case, the Risk, Issue, Quality and Lessons
Learned Logs, and checks that all other information and documentation is correct. Among these other
checks are:
Checking that the Project Management Team members are still appropriate, or that new members are
required, e.g. a new supplier is needed in the next stage. Is the Project Approach still working, and does
the Project Quality Plan strategy need adjusting? Does the Communication Plan need updating for new
interested parties? Update the Configuration Item Records to ensure that they are in agreement with the
actual status of products.
An End Stage Report is prepared to present to the project board summarising the results of the current
stage along with the high level of view of the project and business case. This is accompanied by the Next
Stage Plan.
In summary, SB is used to create and update all relevant project information so that the project board can
make an informed choice about whether or not to proceed with the project. PROCESS
Controlling a Stage (CS) Part One
The project manager is given responsibility for day-to-day management of the project, one stage at a
time. As part of an End Stage Assessment (or an Exception Assessment), the Project Board will hopefully
approve the Next Stage Plan (or Exception Plan).
They will also advise the Project Manager how often they want to receive Highlight Reports, and they will
set Stage Tolerance so that “Management By Exception” can operate.
The CS process is used by the project manager to manage each stage, once the project board has
approved the stage or exception plan.
Once a decision has been taken to proceed with work and resources have been committed, the project
management team must be focused on delivery within the tolerance laid down.
During the stage, the project manager must ensure that the stage's products are passing their quality
criteria and being approved, that the resources used and forecast are sufficient for the remainder of the
Stage, that the risks are kept under control, and the business case kept under review.
The Project Manager has the authority, providing the stage is forecast to fall within Tolerance, to take any
corrective action that they believe necessary.
Note that the Project Board Executive is responsible for the Business Case but regular management and
updating of that document may be delegated to the Project Manager.
During the Stage, the Project Manager, will authorise new Work Packages, receive regular checkpoint
Reports from the team, and create regular Highlight Reports to the Project Board.
PROCESS
Controlling a Stage (CS) – Part Two
Controlling a Stage consists of the following key activities:
1. Authorising work packages and ensuring that they are accepted by the specialist team
2. Receiving regular feedback on the Work Package status, and assessing the bigger picture of
actual stage progress
3. Receiving advice of completed Work Packages and ensuring that they are complete and all
arrangements have been carried out in a satisfactory manner
4. Create regular Highlight Reports to keep the Project Board informed of stage progress – both in terms of
actual progress and future forecast. The Highlight Report will also contain information such as budget,
schedule, issue, risk, and tolerance situations.
5. Reviewing the remainder of the stage and ensuring that it can be completed within tolerance, and taking
corrective action if needed, when the stage is forecast to complete within tolerance
6. Capture and examine project issues including an impact analysis on each
7. Escalate project issues to the project board if tolerance is forecast to be exceeded,
via an Exception Report
PROCESS
Managing Product Delivery (MP)
The objective of this process is to ensure that planned products are created and delivered by the specialist
team under the control of a Team Manager or the team themselves. PRINCE2 takes the view that the job
of the project manager is to manage the team, not to do the work of product creation.
MP allows a controlled break between the project manager and product creation/provision by third party or
internal suppliers. The Stage Plan is split into Work Packages (each containing at least one Product
description), and these are authorised by the project manager, and then given to the specialist team who
needs to agree that they will carry out the Work Package. Optionally, a Team Plan can be created as part
of agreeing the Work Package.
Once the Work Package has been agreed then work will start in creating the products within the work
package, and carrying out quality checks such that the products meet the quality criteria contained within
each Product Description.
As each product is approved, arrangements must be made so that the product is protected from change or
damage. If the product type allows, the product will often be returned to the Configuration Librarian.
The team or Team Manager must key the project manager informed of the Work Package progress, by
sending regular Checkpoint Reports (or meetings) to the project manager, and keeping the Quality Log
updated.
The Quality Log contains planned, and eventually, actual dates of all specialist product quality checks.
Once all products have been approved and authorised, then the work package is complete, and the project
manager must be informed so that this can be agreed.
As each Work Package is finished, the Project Manager must agree that the work and product creation is
satisfactory. This may trigger a new Work Package, or preparation for an End Stage Assessment.
PROCESS
Closing a Project (CP)
The purpose of this process is to execute a controlled shutdown to the project. One of the defining
features of a project is that it is finite -- in that it has a start and an end. If the project loses this
distinctiveness, it loses some of its effectiveness of a purely operational management approaches.
This process may be used for either a "natural" close or a premature close should it ever be necessary.
Closing a Project is triggered during the last stage after all specialist products have been created. It
should not be used in a final stage solely for the purpose of closing the project. The main activities and
management products created during this process are:
1. Customer acceptance against the acceptance criteria
2. Confirm that the maintenance and operation arrangements are in place including any relevant training,
and configuration management arrangements.
3. Make any arrangements for future work (Follow-On Action Recommendations), such as pending status
issues, operational risks, and any other unfinished business
4. Create a Lessons Learned report from the Lessons Learned Log (what we did well, what could be
improved, and any recommendations for the future).
5. Produce a Post Project Review Plan (how the benefits will be tracked measured and realised,
including key milestone dates). The project only has to create the plan, not manage it.
6. Prepare an end project report which is based against the original signed off PID.
7. Advise all those who loaned resources to the project, that the project is about to close, and prepare a
recommendation to the project board of the intention to close the project.
PROCESS
Planning (PL)
This process is used whenever a plan is needed, that is, to create a:
Project Plan
Stage Plan
Team Plan (optional)
Exception Plan (if needed)
Each plan will include products, activities and resources, along with appropriate controls.
Having designed the plan, the first step is to define and analyse the products using the Product-Based
Planning Technique. This technique consists of four steps:
1.
2.
3.
4.
Create
Create
Create
Create
a product description for the end product
a product breakdown structure (a hierarchical diagram)
product descriptions for the main lower level products
a product flow diagram (shows the sequence of creation of the products)
Next, the activities and their dependencies are determined and estimated.
These activities are now scheduled, which includes normal project management planning activities such as
PERT, Gantt, CPA, Resource levelling, etc.
The risks are analysed and any countermeasures included within the plan. Finally the supporting narrative
is added, and the plan document is complete.
COMPONENT
The Components (HOW)
The 8 components may be considered as "approaches", and are referenced and applied as if needed when
carrying out each process.
Business Case
The business Case set out why the project is needed. It evolves from the reasons given in the mandate,
and the fully formed business Case is contained within the PID.
The business case is used as the driving force behind the project. If a satisfactory business case does not
exist, then the project should not be started.
From then on, it should be checked to see that a viable business case exists on a continual basis
throughout the project. As a minimum, the business case should be updated and reviewed at the end of
each stage.
The business case contains:
-
the reasons why the project outcome is needed
options that have been considered to deliver that outcome
the benefits expected - clearly defined in measurable terms
a summary of the key risks
key cost and timescale data extracted from the project plan
an investment appraisal and its evaluation.
The benefits in the Business Case are used as a reference when Closing a Project, to create the Post
Project Review Plan.
COMPONENT
Organisation – Part One
The PRINCE2 project management structure is based on a customer/supplier environment.
The organisation structure includes the project management team and any optional roles.
PRINCE2 does not define how many people should be involved in the project, rather, it sets out a number
of roles that maybe filled by one or more people, or a single person may hold more than one role.
Each role should define the levels of authority required, and may also include the relevant knowledge,
skills, experience, and commitment/availability to fill the role.
For larger projects it may be helpful to agree a formal job description.
The main roles are Corporate (who issue the Mandate and set project-level Tolerance), and the project
management team. The Project Management Team consists of:
The Project Board – they are responsible for ensuring that the project remains on track to deliver products
of the required quality, and that the business case remains viable.
The Project Board Executive role owns the business case and is ultimately responsible for the success or
otherwise of the project.
The Executive represents the business viewpoint of the project, and is responsible for business assurance.
The two other project board roles are the Senior User and Senior Supplier.
The project board executive will take notice of the other two roles advice, but always has the authority to
take the final decision.
COMPONENT
Organisation – Part Two
The Senior User role represents those who will either use the final product, achieve an objective for them,
used the end result to deliver benefits, or they will be impacted (hopefully in a positive way!), by the
project outcome.
This role is also responsible for User Assurance.
The Senior Supplier role needs to achieve the results required by the Senior User, and represents the
interests of those designing, developing, facilitating, procuring and implementing.
To do this the senior supplier is accountable for the quality of products delivered by the suppliers and that
supplier resources of all types (this includes provision of the specialist team), are appropriate.
This role is also responsible for Supplier Assurance.
The project board as a whole is responsible for Project Assurance in the form of Business, User, and
Supplier Assurances as stated above.
Each role may decide to carry out their own assurance responsibilities, or optionally may decide to
delegate it.
The project board members are usually part time and drawn from the existing management structure
within the organisation. It is recommended that project board members should remain with the project
until its close whenever possible.
COMPONENT
Organisation – Part Three
The Project Manager
The project manager is responsible for day-to-day management within each stage within the constraints
laid down by the project board, such as tolerance.
The project manager is responsible for the creation of the PID, which includes the project plan, giving
regular highlight reports to the project board, authorising work packages to the specialist team, ensuring
that product creation is on track and that the products are of sufficient quality, and that the work packages
are completed satisfactorily.
The project manager is also responsible for most of the work during the managing stage boundaries
process. This includes creating the next stage or exception plans, and updating the relevant
documentation at each stage end.
There are several optional roles which may be filled - however, if no one is available then the project
manager must perform these roles them self. They are:
Project support, configuration management, and team managers. The project manager may decide to
issue work packages and receive work package status reports (Checkpoint Reports), directly to the
specialist team themselves.
However, there are situations where the optional team manager role may be required. For example, if the
team size is too large, the specialist nature of the products are unfamiliar to the project manager, where
the team lives over a large geographical area, or where a third party organisation is involved in the
creation of the products, and they wish to use their project manager to act as a team manager within the
project.
COMPONENT
Controls – Part One
The purpose of project controls is to ensure that the Business Case remains viable, that the specialist
products are meeting their quality criteria, and that the project is on schedule and meeting its results and
cost plans.
Controls are built into the project to ensure that progress is monitored, compare achievement against
plans, detect problems early and react, and that those plans are regularly reviewed and updated.
There are 26 different controls within PRINCE2, most of these are event-driven apart from two, the
highlight reports and checkpoint reports - these are time-driven (produced on a regular timed basis).
The event driven controls are used when a particular event occurs - such as the end of a stage triggers an
end stage assessment.
The controls are split into two sections - the controls used by the project board, and those used by the
project manager.
Of particular interest is the use of Tolerance.
Tolerance is the permissible deviation from a plan without bringing that deviation to the attention of the
next higher authority.
Tolerance is built into a plan to allow for small problems and estimating errors (plus and minus), and
should not be confused with a contingency budget (there to cover contingency actions should the linked
risk occur), and a change budget which is there to pay for any changes.
COMPONENT
Controls – Part Two
Tolerance forms a vital part of management by exception, and can exist at three levels:
Project level tolerance. Only corporate management (who created the Project Mandate), have the
authority to set project-level tolerances.
The Project Board has the authority to set stage-level tolerances, and optionally, the project manager may
set tolerances at the work package level.
It may be more helpful to consider grouping the controls in the general sequence that they would normally
be used:
At the start of a project.
This will include the Starting Up a Project and Initiating a Project processes, project-level tolerance, the
project initiation document, the selection of stages to be used, and the two project board review points:
Authorising Initiation – the Project Board check that it is sensible to invest in a PID
and
Authorising a Project – the Project Board check that the project is viable and worth doing.
The PID encourages the Project Board to take ownership of the project - the PID is also used as a
“baseline” reference showing the project’s original intentions.
COMPONENT
Controls – Part Three
During The Stages
This is where most of the controls occur, and I will just list them here:
1. Creation of Stage or Exception plans, the end Stage Report, definition and authorisation of Work
Packages, and their Product descriptions and quality criteria, approval at each End Stage Assessment
or Exception Assessment
2. Setting of stage tolerance, quality control during the stage, project issues and change control, risk
analysis and risk management, checkpoint and highlight reports, and the daily log.
Closing a Project
These controls include:
1. Customer Acceptance
2. The End Project Report (a review of the project against the initial PID)
3. Follow-on Action Recommendations (any unfinished business)
4. The Lessons Learned Report (drawn from the Lessons Learned Log)
5. Operational and Maintenance Acceptance (confirming the end product can be operated/supported)
6. The Post-Project Review Plan (how and when the benefits are measured and tracked, the resources
needed to do this, and key dates leading to the Post Project Review itself where the previous project
board executive determines that the benefits in the business case have been realised). COMPONENT
Management of Risk – Part One
Risk can be defined as uncertainty of outcome, but perhaps a more helpful definition would be “a risk is
something which has yet to happen, it may or may not happen, but if it does it will have an impact in some
way on the project or business case”
The project board has four risk responsibilities:
1. Keeping the project manager informed of any external risk exposure to the project
2. Agreeing or otherwise to the project managers planned risk actions
3. Ensuring that there is a balance between the level of risk and the business case benefits
4. Keeping corporate and other senior stakeholders of any risks that may affect their objectives.
5.
The project manager is responsible for ensuring that risks are identified, recorded and regularly reviewed.
Each risk should be allocated an "owner" - defined as the person best situated to keep an eye on it. The
project board and project manager may themselves own particular risks.
All risks and their details are entered on to the Risk Log. This is kept updated throughout the project.
New risks may arise, and existing risks may change - for example become more or less likely, their
impacts may increase, the increase, or change. As a result of those, new actions or countermeasures may
need to be planned.
COMPONENT
Management of Risk – Part Two
The management of risk is split into two main steps:
1. Risk Analysis
2. Risk Management.
Risk Analysis has four steps:
Risk identification
Usually captured at planning or risk workshops - although they may be identified at any time during the
project
Each risk should be categorised under one or more of seven categories:
1.
2.
3.
4.
5.
6.
strategic/commercial
economic/financial/market
legal and regulatory
organisational/management/human factors,
political, environmental
technical/operational/infrastructure.
Risk Evaluation
This consists of determining the probability of each risk, and its impact. In fact should be considered
under the following headings: Time, cost, quality, scope, benefit, and people/resources.
COMPONENT
Management of Risk – Part Three
Identify suitable Responses to Risk
All responses should be built into the appropriate plan. There are five main action types that may be used
singularly or in combination:
Prevention. Countermeasures are put in place to reduce the probability to zero and/or reduce the impact
to zero.
Reduction. Actions are taken to reduce the probability and/or reduce the impact
Transference. The risk in total in his passed to a third party usually in the form of a contract penalty
clause, or an insurance policy. Be clear that the risk, if it occurred must have no impact on the project.
For this reason, not all risks can be transferred.
Acceptance. It is agreed that if the risk occurs, the impact to the project can be tolerated. This action
may be chosen because any such actions would have an impact, such as cost, that is out of proportion to
the risk impact itself.
Contingency. This is different to all of the above. Actions are determined for the risk only if and when it
occurs. Such actions must also be built into the plan, and in some cases a contingency fund is set up,
separate and distinct from the main project budget. The final step of Risk Analysis is:
Select. The above actions should be considered and those chosen should be done so by balancing the cost
of such action against the probability and impact of the risk occurring.
COMPONENT
Management of Risk – Part Four
Risk management.
This consists of plan and resource, and, monitor and report.
Plan and resource is taking the selected responses above, and including the activities and resources
needed to carry them out.
Once the plan is signed off, then monitoring and reporting can take place.
This will normally consists of checking that the actions are having the desired effect watching for warning
signs and trends, and ensuring that the overall management of risk is effective.
The Management of Risk is an ongoing and iterative activity throughout the project and its stages.
The total risk situation should be checked at key points - particularly at those times when the project board
needs to authorise a Next Stage Plan or Exception Plan.
The risk situation should be included in the regular highlight report. Also the risk situation should be
checked when:
1. Planning, authorising and accepting Work Packages
2. Examining project issues, as part of management by exception
3. When closing the project.
COMPONENT
Quality in a Project Environment – Part One
Within projects, quality is a question of identifying what it is about the project's products or a service that
makes them fit for their purpose of satisfying stated needs. Projects must not rely on implied needs.
It is important to ensure that both sides of the customer and supplier environment are actively involved in
ensuring project quality.
In particular, the use of project assurance, who must be independent of the project manager, and "reassure" the key business, user, and supplier interests that the project is being run in an appropriate
manner.
Also, project assurance should have heavy involvement in the planning and the use of appropriate
resources during quality checking off the specialist products.
PRINCE2 has created an easy-to-follow "Path to Quality", that lays out in sequence the key points within
the project when quality should be checked.
Here is the sequence:
1. The customers quality expectations are gathered
2. These are prioritised into measurable acceptance criteria
3. The Project Approach (how the work of the project is to be approached), is created, based upon the
Acceptance Criteria.
The project approach is a pre-requisite to planning.
COMPONENT
Quality in a Project Environment – Part Two
The Project Quality Plan is created “How quality is to be achieved”, and this should include responsibilities
for quality and any special standards that will need to be met.
The blank Quality Log is set up.
The Quality Log will be used to capture the planned, and eventually actual, dates, of all specialist products
quality checking. As such it may be seen as a progress tool.
During the creation of all plans, and using the Product-Based Planning Technique, product descriptions are
written in close consultation with the users, and quality criteria agreed for each product.
Each stage plan should include its own Stage Quality Plan. The Stage Quality Plan ensures that the timing,
method, and resources needed for all quality checking identified and included.
At this point, the Quality Log will have the planned date for all quality checking within the stage added.
Once the specialist team has agreed to execute the Work Package, then work commences on the creation
of the specialist products.
When each product has been created, it is submitted to the agreed Quality Check laid out in the Product
Description.
Once passed, the product is approved and usually given to the Configuration Librarian. The Quality Log
should be updated with actual dates of the Quality Check.
COMPONENT
Configuration Management – Part One
Within the context of a project, Configuration Management can be considered as version control.
Configuration Management is used to manage assets of a project - which are the products created by the
project. All specialist products must come under the control of Configuration Management, but so too
should the management products - with the exception of the various Logs. The name for the combined set
of these assets is a configuration, and the configuration of the end product is the sum total of all its
products.
Configuration Management should be a permanent part of an organisation, since once the project has
finished, the end product needs to be managed throughout its life. The job of Configuration Management is
to identify, track and protect the project products. The project manager is responsible for Configuration
Management, and as above, will normally liaise with the Configuration Librarian to ensure that
Configuration Management is carried out.
Configuration Management and Change Control must work very closely together, and it is usually the
Configuration Librarian that maintains the Issue Log on behalf of the project manager.
The Configuration Management Plan is included as part of the Project Quality Plan and it is a strategy of
how Configuration Management should be used for the project and its products. This Plan should include
how and where the products are stored, what filing and retrieval security there will be, how products and
their versions will be identified, and where responsibilities for Configuration Management lie. Configuration
management consists of five basic functions:
Planning and identifying what level of configuration management will be needed by the project, and
specifying/identifying all components of the final product.
Control. This is the ability to agree and baseline products, and then only to make changes after
agreement by the appropriate authority (normally the project board).
COMPONENT
Configuration Management – Part Two
In order to exercise sufficient control, there must be close liaison between the Configuration Librarian and
those creating the products, so that as the status of a product changes, its state is kept under control.
When a management product is authorised by the Project Board, it is "baselined", and therefore moves
from draft status to approved status. This changes its status and "freezes" the content - so that it can now
be used as a firm basis for the development of any later product, only to be changed under formal change
control.
Most importantly, this process also applies to specialist products.
When a specialist product passes its quality check, it moves from the draft to approved status. Where
appropriate, the Configuration Librarian holds master copies of products.
The Configuration Librarian also controls the issue of copies of a product, for example a document, so that
it can be referenced and used. Where a copy of a product is needed for modification, for example an issue
such as a request for change, the Librarian will issue the copy and ensure it is still under control.
Status accounting. The configuration librarian maintains full records of the status of all products and a
full history concerning each.
Verification. The configuration librarian provides a service of reviews and audits to ensure that the actual
status of products match is their status held within configurations management records.
Such audits are particularly useful when preparing for an end stage assessment and when closing a project
- but they may be requested at any time.
COMPONENT
Change Control – Part One
PRINCE2 covers change control within three areas:
1. The Change Control Component (this one)
2. The Change Control Technique
3. The management of Project Issues during the Controlling a Stage process.
The last two are dealt with in other sections of these Summaries.
Within PRINCE2, all changes are treated as a type of project issue.
Two important guidelines are stated:
1. If a product is to be changed, its product description should also be checked to see if it too, needs to
be changed
2. Once a plan has been approved by the Project Board, any products referenced within the plan must
not be changed without the approval of the project board.
A project issue can be a general issue - which could be for example, at advice of a new risk, a general
query, an observation or concern, or even a good idea.
Such issues only use the Issue Log when a formal decision is needed.
COMPONENT
Change Control – Part Two
Apart from general issues, there are two remaining categories:
A Request For Change (RFC).
This type will cause a change to the existing acceptance criteria, functional specification, or scope in some
way. An RFC is raised from the customer side, and if any additional costs are incurred by the request,
then the customer would normally pay for these costs.
An Off-Specification.
This type covers errors or omissions than in work already carried out, or planned for the future - and will
result in the project not being able to meet the existing acceptance criteria, functional specification, or
scope. Additional costs to fix this problem will normally be borne by the supplier.
If the project board agrees to accept an Off-Specification without the need for corrective action, then this
is called a Concession.
The project board may decide to delegate their authority on decisions for project issues, to a person or
group that carried this out for them – they are called a "Change Authority".
In addition the project board may agree to a separate Change Budget been set up to pay for any agreed
changes. This has the added advantage of stopping tolerance being used to pay for changes.
Project Issues should not be considered in isolation, but should be balanced against Business Case
benefits, the risk situation, and any possible extra cost all-time being incurred.
COMPONENT
Plans Component
The Plan Component makes the point that a plan is a document - not, for example, just a scheduled
diagram (Gantt Chart, etc,).
The benefits of creating a plan are many, and include the products, activities and resources needed to
achieve the targets within an agreed timeframe, agreeing assumptions, constraints, risk countermeasures,
dependencies between products and activities, and the points at which progress will be monitored and
controlled.
There are three levels of plans that may be used:
1. The Project Plan
2. Stage Plans
3. Team Plans (optional).
Should it be necessary, an Exception Plan may be created, which if approved, would replace the existing
plan that will no longer finish within tolerance. The Exception Plan is not a different level.
Apart from Team Plans, the Project Board approve all plans and in doing so, authorise the time and
resources contained within them.
The project board uses the Project Plan as their base reference, while the project manager uses the Stage
Plan to monitor, manage, and control each stage.
Plans also have an important function of proving that targets can be met, identifying the resources needed,
and assisting in many communication aspects of the project.
TECHNIQUES
PRINCE2 includes just three techniques, and makes no attempt to describe any other business or project
management techniques - such as critical Path analysis, earned Value analysis, the creation of control
techniques such as Gantt and PERT and financial techniques such as investment appraisal.
Project Based Planning Technique – PART One
This is the most important technique, and must be used first to identify the products of a plan, before
activities and resources are considered.
A product is anything that the project must produce in some way and is described by the use of a simple
noun or outcome.
For example, Help Desk, New Help Desk, or possible Refurbished Help Desk. Compare and contrast this to
a task, which is described by the use of a noun and verb. For example, create report, write the report,
test the software, etc.
As described earlier, the technique consists of four steps:
1. Create a product description for the end product
2. Create a product breakdown structure (a hierarchical diagram)
3. Create product descriptions for the main lower level products
4. Create a product flow diagram (shows the sequence of creation of the products)
TECHNIQUES
Product-Based Planning Technique – Part Two
The Product Breakdown Structure.
This is a hierarchical diagram showing all the products that must be created within the scope of a plan.
Remember, this diagram does not show sequence - only a "family tree" type of diagram. When creating
the project plan, the product breakdown structure would only include top-level products.
When producing a product breakdown structure at stage plan level, these products would be broken down
into lower levels.
TECHNIQUES
Product-Based Planning Technique – Part Two
At the top of the product breakdown structure diagram is the end product, and this is broken down into
lower levels. Products at the lowest level are called simple products because they cannot, or do not need,
to be broken down into more detail.
The standard shape is a rectangle. Products in the "middle" of the diagram are called intermediate products.
There are two main types:
Intermediate Collective.
This type is just a convenient way of grouping products that have a common theme such as hardware,
software, food, drink, documentation, etc.
To help identify and intermediate collective product, it is suggested that a different shape is used - that of
a rhomboid.
These are not real products, but merely a device to help remind the planner of what the real products are,
and these are drawn as sub products under the collective rhomboid.
TECHNIQUES
Product-Based Planning Technique – Part Three
Intermediate Integration.
This product shape is drawn as a standard rectangle.
However, the sub products below it must be assembled, tested, integrated, and prepared in some way to
create the intermediate integration product itself.
Examples are, a hardware product assembled from its sub products, a document that uses various sources
of information that are included within the document, or a named food dish that uses the ingredient subproducts below it.
Another type of product is an external product, and an ellipse should be used as its shape.
An external product is one that already exists, but the project needs it in order to achieve the project
objectives. Another example is where the product is to be supplied from sources outside of the scope of
the project.
This does not include when the work package is given to third parties - as these products are still under
the control of the project and progress information is obtained from such teams.
TECHNIQUES
Product-Based Planning Technique – Part Four
Product Descriptions
Product descriptions should be written as soon as the need for the product has been identified.
It is a good idea to involve the users or customer involved in the creation of product descriptions,
particularly defining the quality criteria, and how the product may be checked against these criteria.
The suppliers must also be involved to ensure that the product description is realistic and achievable.
The product description contains key information including:
1. The purpose
2. Composition of the product
3. How the product is to appear and be presented
4. The quality criteria that the product must meet
5. The people or skills needed both to create the product and carry out the quality checking.
Some product descriptions can be created when producing the project plan in the initiation stage, while
others may not be completed, or even identified until planning of a future stage.
TECHNIQUES
Product-Based Planning Technique – Part Five
Product Flow Diagram.
This shows the sequence of creation of all of the products identified in the product breakdown structure
diagram, where the final product in the sequence will be the end product. However, the integration
collective rhomboids have no value at in this diagram at as they were not real products and only used in
the product breakdown structure to help identify the real sub-products beneath.
Because the product flow diagram shows the sequence, then each product shape will have at least one
arrow going into it - and at least one coming out of it.
This diagram has the added advantage of helping the planner to identify dependencies between one
product and another and any opportunities to develop some products in parallel.
TECHNIQUES
Change Control Technique – Part One
This technique demonstrates how each project issue should be processed.
The Project Board is responsible for the Change Control procedure. However, it is the Project Manager,
with possible help from project support and Configuration Management, is responsible for applying this
technique within the Controlling a Stage process.
Anybody with an interest in the project may raise an issue at any time, and this is when the change control
technique is used.
When an issue is raised, it should be entered into the issue log, categorised according to the type of issue,
and a copy sent to the author to advise its receipt and entry into the issue log.
An Impact Analysis of the issue is now carried out, and should include:
1. What would have had to change
2. What effort the change would need
3. What is the impact on plans would be (including if the issue would cause Tolerance to be exceeded),
4. What the impact would be on the business case and risks.
If the issue is an off-specification, then the project manager may try to resolve the issue within
tolerance if this is possible.
But for requests for change, the project manager must always bring this to the attention of the project
board since it is they who have the authority to agree or otherwise.
TECHNIQUES
Change Control Technique – Part Two
The Issue Log should be constantly updated to show the reader the current status and progress of the
particular issue.
Issues can cause existing risks to change – or create new risks. For this reason, the Risk Log should always
be inspected when examining an issue.
The author of an issue should include their opinion of the Priority of the issue, for example “must-have” or
“cosmetic only”.
After Impact Analysis has been carried out, the Project Manager – or the Project Board, should re-evaluate
the Priority rating.
Should any issue cause a forecast of tolerance to be exceeded, then the project manager must follow the
management by exception process, and raise an Exception Report for consideration by the project board.
If the issue were to cause project tolerance to be exceeded, then the exception report must be passed
upwards to Corporate Management.
When considering changes, the project board has the authority to implement the change, reject the
change, and place it in "pending" for possible implementation later or if possible, to remove the cause.
TECHNIQUES
Quality Review Technique – Part One
When product descriptions are created and the quality criteria determined for the product, a suitable
method must be chosen to carry out the quality check.
Where the product quality criteria can be checked by a test or instrument that clearly demonstrates that
the product has either passed or failed, then the method used to carry out that check can be by any
sensible and appropriate method.
But where the quality check outcome may be more subjective - such as ease of use, a document's
readability, etc, then the formal quality review technique should be applied.
The objective here is to check the product itself against the quality criteria, and identify any errors,
defects, observations or questions.
There are four roles involved in the (formal) Quality Review:
1. The review chairperson
2. The producer or creator of the product
3. The reviewer or reviewers
4. The scribe who is there to take the minutes.
TECHNIQUES
Quality Review Technique – Part Two
The Quality Review Technique consists of three basic steps:
1. Preparation. The product is reviewed against its quality criteria, and a question or error list created
by the reviewers.
2. Review meeting. The review meeting is conducted under control of the review chairperson, and
continues until an agreed outcome is arrived at:
1. The product has passed its quality review, and can be signed off
2. The products as errors and needs some form of rework
3. The reviewers cannot agree on the outcome of the meeting. This would likely result in the action to
raise this as an issue once the meeting has finished.
3. Follow-up. If the product has passed its review then the quality log should be updated to reflect
this, and arrangements made to store or protect the product. It is often given to the
Configuration Librarian for this purpose, and also to allow for consideration records
to be updated.
If the product did not pass, then the follow-up actions will need to be carried out. The project manager
will normally be immediately informed, and extra activities and resources added to relevant work packages
and plans.
If such rework were to cause tolerance to be exceeded, then an exception report must be created and sent
to the project board for their action.
APPENDICES
Appendices Part One
The PRINCE2 Manual has 5 appendices:
Appendix A. This contains 36 Product Description Outlines. These are “templates” for all of the
management products, and are presented in alphabetical sequence.
For example the project plan, project initiation document, and risk logs can then be found here. However,
it also includes a single product description template for creation of the specialist products.
Appendix B. Project Management Team Roles. These contain the responsibilities and tasks for each
member of the project management team. They may be used to generate job descriptions
for the individuals that hold these roles.
Appendix C. These are the seven Risk Categories including many examples that were
mentioned previously in the management of risk component.
Appendix D. PRINCE2 Healthcheck. These have been designed so that an organisation can check on
its correct and appropriate use of PRINCE2.
It is in the form of sets of questions under several general headings such as
organisation, business case, and risk.
Appendix E. Project Document Management. Should an organisation need it, PRINCE2 has
a suggested document management structure hierarchy that can be used by project to hold
the various management documents.
APPENDICES
Appendices Part Two
Appendix E This is split into three sections:
The Project file.
This contains documents that address project level interests such as the organisation, project plan,
planning technique documents, business case, risk log, and various control documents including the
communication plan.
The Stage Files.
This section would be subdivided, one for each stage - and would include items such as, stage level
organisation and plans, control documents such as work package authorisation, reports, ended stage
assessments, and relevant correspondence.
The Quality File.
This covers quality matters for the entire project. It includes the customers' expectations, acceptance
criteria, the project quality plan, configuration item records, and the quality log and issue log.