PRINCE2 walkthrough and Roadmap - projex.com · Step By Step Guide PRINCE2 walkthrough and Roadmap Dave Litten

Step By Step Guide

PRINCE2

walkthrough

and Roadmap

Dave Litten

www.projex.com

PRINCE2 Walkthrough and Roadmap Projex Academy

Projex Academy |prince2_walkthrough_roadmap_v1.1 |© David Geoffrey Litten 2018 2

Copyright

Copyright © 2018 Projex Academy

Cover and internal design © Dave Litten

https://www.projex.com/prince2-masterclass/

All rights reserved. No part of this book may be reproduced in any form or by any electronic or

mechanical means including information storage and retrieval systems – except in the case of

brief quotations in articles or reviews – without the permission in writing from its publisher,

David Geoffrey Litten

All brand names and product names used in this book are trademarks, registered trademarks, or trade names of their respective holders.

http://www.projex.com/prince2



PRINCE2 Walkthrough and Roadmap Congratulations!

YOU have taken the first step toward a PRINCE2 EXAM PASS!

My Roadmap Walkthrough is a key diagram that I normally develop for the delegates on the first morning of my PRINCE2 training seminars. As you will see from the attached diagram, it is just a picture taken from one such training session.

This important diagram, shows the interaction between the seven PRINCE2 Processes in a typical project and the key PRINCE2 Management documents, and as such teaches you how the PRINCE2 Method is applied. www.projex.com Good Luck on your path to your PRINCE2 exam pass…





PART ONE – An Overview of the PRINCE2 Method

I suggest you print out this document and keep the roadmap diagram separate so that you can

refer to it constantly as I guide you through it. As is usual, I will start at the top left-hand corner

of the diagram with the ‘trigger’ for any PRINCE2 project – the Project Mandate…read on…

A project can be standalone or part of a programme, in which case a project may be triggered

from either those within a programme, here called programme management, or by appropriate

senior management within an organization, here called corporate management.

A PRINCE2 project is therefore triggered by either of the above by issuing a Project Mandate.

This document should contain as a minimum, the name of the prospective project board

executive and the reasons for the need of the project.

As such it may only be and verbal instruction or possibly an e-mail. At the other extreme it

could be the final report from a feasibility study.

Whichever, it must contain sufficient information provided by an appropriate authority level, to

trigger the first PRINCE2 process.



The first process is called Starting Up a Project and uses the initials SU. This occurs pre-project

and is used as a solid foundation prior to the first stage in a PRINCE2 project.

Developing detailed plans can consume a lot of resource, and since many projects should not

even be started in the first place, it makes sense for SU to be used as a ‘filter’ – both to prevent

poorly conceived projects from starting in the first place, and to establish an understanding of

the goals and objectives of the project.

To ensure that there are good business reasons to proceed with the project.

One of the first activities is to appoint the Executive of the Project Board and the Project

Manager; the Executive will now design and appoint the remaining roles within the Project

Board including who will fill the Senior User and Senior Supplier roles, and how Project

Assurance is to be handled.

The project manager will design and appoint any other supporting roles that will be needed

such as project support, configuration management and the optional Team Manager role.

There are two main management products that are an output from this process, the Project

Brief and a plan for the Initiation Stage.

The Project Brief contains the outline Business Case with sufficient information to justify

carrying out the initiation stage, creating the Project Product Description which includes

aspects such as the customer’s quality expectations and acceptance criteria for the end product

of the project.

The Project Brief also contains the Project Approach management document. This lays out the

approach used by the project to deliver the end product, for example, basing the design on an

existing product or developing an entirely new design, or whether or not resources used for the

project will be provided internally or by the use of third parties.

The Project Brief is a refinement of the Project Mandate, and in a similar way the Project Brief

will be refined further within the initiation stage to become the Project Initiation

Documentation (PID).

One important principle of PRINCE2 is that of manage by exception. The purpose of this is to set

tolerance levels at the directing, managing, and delivering management levels within a project.



Tolerance is defined as limit within which a specific level may manage without the need to

escalate to the next level above.

There are six objectives against which tolerances may be set: time, cost, quality, scope, risk, and

benefits. If any of these tolerances are forecast to be exceeded, then an Exception Plan must be

raised which if approved would replace the existing plan that would have no longer completed

within tolerance.

Corporate or Programme management have the authority to set project level tolerances, the

Project Board have authority to set stage level tolerances, and optionally, the Project Manager

may set tolerances around each specific Work Package.

One of the PRINCE2 principles is learning from experience. For this reason, the Lessons Log is

created and filled with any lessons that can be learned from appropriate individuals and

previous similar projects.

The project manager would be expected to proactively collect such data. The Lessons Log will

be updated and used throughout the project, as a source of information to create the optional

Lessons Report at the end of each stage, and the Lessons Report that is created as part of the

Closing a Project process. In this way, lessons can be passed on to future similar projects.

The Daily Log is also created by the project manager and is used as a ‘diary’ by the project

manager for the remainder of the project. But here in SU, it is also used to capture any risks and

issues that need to be managed prior to the formal start of the project.

To proceed any further, the newly formed project board will need to decide whether or not it is

worth investing in the creation of the PID. Specifically, how much work effort and resources are

needed in the initiation stage.

In this way, poorly conceived projects can be nipped in the bud before any further effort is

wasted upon them. By the same token, the information contained within the Project Brief and

the initiation Stage Plan will give the project board sufficient information to make an informed

choice.

The Starting Up a Project process culminates with the project manager requesting that the

project board consider authorizing the initiation stage. This uses the first activity ‘authorizing

initiation’ within the directing a project (DP) process.



The project board may decide not to proceed any further. However, let’s assume that in this

instance they agree based on the evidence above to invest in the initiation stage, then this will

become the formal start of the project, and corporate/programme management will be

informed that the project is initiated.

The initiating a project process is used within the initiation management stage and the main

deliverable here is the PID itself. The activities within this process echo the contents of the

project initiation documentation. It makes sense to first determine the various approaches

needed within the project be for detailed planning takes place.

The Risk Management Approach document is created and the Risk Register is set up to capture

and manage any risks throughout the project. Any risks which exist already on the Daily Log

would now be transferred to the Risk Register. The Risk Management Approach defines HOW

resource will be managed throughout the project.

The Quality Management Approach document is created and the Quality Register is set up. This

register will typically be empty at this point, as this will contain the planned dates of all quality

management activities for the creation of the specialist products, and such dates will not be

known until the second Stage Plan is created.

This second stage is always the first delivery stage, so-called because this is the first stage (and

possibly also the final stage for small simple projects) where specialist products are to be

created.

The word specialist products refer to the type of project, for example if the project end product

is a new office building, then the specialist products would be for example, the building frame

itself, roof and walls, water and electricity services to be implemented, heating and lighting

products, office equipment and so on.

These should not be confused with the PRINCE2 management products such as the Project

Brief, Project Initiation Documentation, reports, and so on.

So you can see that the Quality Register will have the actual dates of the quality checking

activities entered during a typical delivery stage.

It is worth mentioning that PRINCE2 does not consider a specialist product as complete, until it

has had an independent quality check and an appropriate authorization.



As part of the PRINCE2 product-based planning technique, a product description for each

specialist product is written as part of planning for a particular delivery stage. This Product

Description will contain the method and the appropriate measurements required for the

product to have ensure the pass its quality check.

The Change Management Approach document is created and the Issue Register is set up. In

PRINCE2, an issue can be advice of a new risk, a problem or concern, or a change. There are two

types of changes: a request for change which typically comes from the customer and it is a

request for a change to what was originally agreed.

The second type of change is called an off-specification; typically, this would come from the

supply side and covers some aspect of the project that although agreed, cannot now be met.

Configuration management may be thought of as version control and as such is closely aligned

with how change control (mentioned above) is to be implemented. Typically configuration

management will be supplied by the project support role.

The final “strategy” is the Communication Management Approach, and is created last because

the first three strategies will have communication needs and these can be included at this

point. As you can see, all four of the strategies are HOW-TO documents.

The Project Plan can now be created in parallel with setting up the various controls there will be

needed throughout the project.

Typically, these controls focus on those needed at project board level for example end stage

assessment timing, and the frequency of their regular Highlight Reports, while at project

manager level for example, the formality or otherwise of issuing Work Packages and the

frequency of the regular Checkpoint Reports.

Highlight Reports cover progress within the management stage, and Checkpoint Reports cover

the progress of specialist product creation within a Work Package.

As with all plans, the Project Plan is a document, and will use the PRINCE2 product-based

planning technique.

Traditional project planning would start with the brainstorming of the various activities. But one

of the principles of PRINCE2 is product focus.



What this means is that the product based planning technique starts with the identification of

products, initially at the highest level within a project, by creating the Project Product

Description, but then going on to create a Product Breakdown Structure which is a hierarchical

diagram of the products within a given project.

The next step would be to create Product Descriptions for all appropriate lower level products,

including their quality criteria. The final product-based planning step is to create a Product flow

Diagram, which shows the sequence of creation of the products.

In case you are confused, an activity would normally be described with a noun and verb such as

‘create report’, whereas a product would be described with a noun or outcome for example

‘specification document’.

Within PRINCE2, the next steps cover traditional planning techniques, first identifying the

activities needed to create each product, then estimating such activities, creating the schedule

or sequence of such activities (usually shown as a network diagram or Gantt Chart view).

This continues, by going on to identify risks, their associated response activities, and finally

adding the narrative of the plan document.

Because of this, new Product Descriptions along with their quality criteria will be created along

with a Configuration Item Record (CIR) for each product. This record forms part of the data and

the status for each product held within configuration management.

Also, at this point the Project Product Description may now needs to be further refined, for

example, as better data is understood for the acceptance criteria of the project end product.

The detailed Business Case can now be developed as it will use timescale and cost information

derived from the Project Plan.

This detailed Business Case will be used throughout the project in particular at the end of each

management stage where it is updated and used as a basis to proceed or otherwise by the

project board.

A new management product is now created based upon some information contained within the

business case, and it is called the Benefits Management Approach. As the name suggests, this

contains a description of each future benefit, its timing, measurement, and the resources

required to carry this out.



The Benefits Management Approach is kept separate from the Project Initiation Documentation

as it will be used after the project has finished to continue and track the remaining benefits

until their eventual realization.

All of the above can now be assembled and forms the Project Initiation Documentation.

The project manager will now request that the project board authorize the project. They will

use this named activity within the Directing a Project process (DP), and this will always be the

first end stage assessment within any PRINCE2 project (as the initiation stage is always the first

management stage in a PRINCE2 project).

However, there is a parallel activity that also needs to take place if this project is to proceed any

further, and that is to prepare a Stage Plan for the next stage.

The Managing a Stage Boundary (SB) process is used for this purpose, and will use the product

based planning technique. As this is the end of the initiation stage then the End Stage Report

will also need to be created along with an optional Lessons Report.

Authorizing the PID will occur within the Authorize the Project activity and authorizing the next

Stage Plan will occur at the Authorize a Stage or Exception Plan activity.

Both of these are activities within the Directing a Project process and will normally take place at

the same meeting which is the end stage assessment.

At this end stage assessment, as is typical, the project board has the option to approve the next

Stage Plan, prematurely close the project, or request that the project manager reworks some

aspect of the documentation.

Assuming all is well, the Project Board will set stage tolerance for the next stage, advise the

project manager of the frequency and detail to be included in the regular Highlight Reports and

approve the next Stage Plan. This will now trigger the project manager to give out the first

Work Package within this newly approved stage.

It is highly likely that the number and detail of Work Packages within a stage and any associated

Team Plans have already been thought through during the planning of the relevant stage.



But whether they have or not, the PRINCE2 method defines that the specialist team should not

start work on any product creation until a Work Package containing such work has been

authorized by the project manager and accepted by either the team manager or the team

members themselves.

The Team Manager role may optionally be given to an appropriate individual within the

specialist team (if the specialist team is a third party, then it may well be that their project

manager takes on the role of Team Manager – but remember, there can only be one Project

Manager).

The team manager may optionally produce a Team Plan which would show that one or many

Work Packages can be delivered within the constraints laid down.

Every Work Package must contain at least one Product Description. The project manager may

optionally set tolerances at the work package level.

Once the Work Package has been agreed and accepted then work can start on the creation of

the specialist products contained within the Work Package.

At any given point during a stage there may be one or several Work Packages, possibly given to

different teams, being worked on at the same time. Alternatively Work Packages may be given

out one after another.

This is clearly a very flexible system and the manner and formality will depend on the nature of

the specialist work within the stage.

Probably 90% of the project budget is spent within the Managing Product Delivery (MP)

process, since this is where the specialist products are created.

The ‘execute a work package’ activity is where the specialist products are created and their

quality checks carried out, followed by their approval by the appropriate authority or individual.

The team manager or the team themselves will produce regular Checkpoint Reports providing

information on the status and future forecast of the creation of specialist products. These are

sent to the project manager, and may be in the form of a report or a meeting.

The project manager will use the activity of Review Work Package Status to determine the

progress or otherwise of the creation and the approval of these specialist products.



Since the Stage Plan has been approved by the Project Board, then the project manager must

look at progress within the stage itself.

If the project manager determines that the stage is forecast to remain within tolerance bounds,

then he or she may take some form of corrective action to minimize any such deviations within

tolerance. This may entail giving out new or modified Work Packages to the specialist team.

In addition to this the project manager will need to review the stage status and use the activity

of report highlights, which will generate a Highlight Report to be given to the project board so

that they understand the current status and forecast future of progress within the stage.

The project manager will update the Stage Plan with actual progress and modifying future

actions to ensure that the stage plan is forecast to complete within tolerance.

As each Work Package is completed, then the team manager or the specialist team themselves

needs to inform the project manager that the Work Package is indeed complete.

The project manager, as part of the activity review work package status will need to agree that

all the products have been completed, met their quality criteria, and have been approved by

the appropriate authority.

This may trigger the authorization of a new/revised Work Package, or that the stage end is

approaching, in which case the project manager would use the Managing a Stage Boundary (SB)

process to prepare for an end stage assessment.

If at any time during the stage, either issues or risks should arise, then the project manager

should use the activity of capture and examine issues and risks to carry out an impact analysis

of these on both the stage and project. The appropriate Issue or Risk Register should be

updated with such information.

If the project manager determines that some corrective action can be taken via the issue of

new or modified Work Packages to resolve the situation then such actions would need to be

taken.



If after impact analysis and the review of this within the status of the stage or the project would

show that forecast of tolerances would be exceeded, then the project manager must create an

Exception Report and bring this to the attention of the project board.

If a Work Package is forecast to exceed tolerance levels, the Team Manager would raise this as

an issue to bring it to the attention of the project manager.

Using the activity escalate issues and risks, the project manager would bring this Exception

Report to the attention of the project board.

Put simply this Exception Report should contain information on the reasons for this forecast of

exceeding tolerances, the impact in terms of the appropriate tolerance, and a set of options,

which if implemented would return the stage of project within tolerance bounds, and a

recommendation of which option should be chosen, and why it is the best option.

This is sent to the project board who now need to decide on what to do next. One option they

have is to prematurely close the project, in which case the project manager would use the

Closing a Project (CP) process to carry this out.

For the moment we shall assume that they prefer another option, either recommended by the

project manager, or one which they have determined. This would trigger the project manager

to use the Managing a Stage Boundary (SB) process

The project board would request the preparation of an Exception Plan using the Managing a

Stage Boundary process.

At this point it would be helpful to state that the Managing a Stage Boundary process has only

TWO uses.

The first is to prepare for an end stage assessment (ESA) by creating the next Stage Plan.

The second is to prepare for an exception assessment (EXA). In the former the objective is to

approve or otherwise, the next Stage Plan, and in the latter it is to approve or otherwise the

Exception Plan.



Whichever of the above, this process would follow the following steps and activities:

1. Create either a next Stage Plan or an Exception Plan

2. Update the Project Plan to show actual progress and if necessary, a modified future forecast

3. As part of updating the Project Plan and the next Stage Plan/Exception Plan, it may be

necessary to update some aspects of the PID (possibly in terms of the strategies, the plan,

and the controls, or the Business Case and related Benefits Management Approach.

4. As a result of the above, new or modified Product Descriptions will need to be created, new

or modified risks and issues entered on to the appropriate registers including any lessons

that have been learned during the stage.

5. The Benefits Management Approach needs to be updated to reflect any products that may

have already being released into the operational (business as usual – BAU) areas.

6. The project manager will produce an End Stage Report and if appropriate create a Lessons

Report.

All of the above will be brought before the project board at either an end stage assessment or

an exception assessment.

The project board will need to decide to either approve the next Stage Plan, or approve the

Exception Plan, or request more information, or to order a premature close of the project.

For each delivery stage these four processes will continue in the same manner as described

above.

The Managing a Stage Boundary process will be used either to prepare a next Stage Plan or an

Exception Plan and is brought before the project board using the Directing a Project process to

either approve or otherwise the next Stage Plan or an Exception Plan.

Once this has been authorized, the project manager will give out the work contained within

that Stage Plan and the specialist team will create the specialist products via each Work

Package.

When the last Work Package has been completed (each specialist product has been approved),

then this will trigger the project manager to acknowledge that the project end is approaching.



A very important point needs to be made here. If the project, within any management stage,

needs to be brought to a premature close, then the closing a project process (CP) is used.

Let us suppose that a given project has three delivery stages after the initiation stage. In the

final delivery stage, work packages containing information on the specialist products to be

created will be issued and managed as described above.

However, once the final specialist product within the final work package has been approved,

then the project manager will trigger the closing a project (CP) processes to shut the project

down in a controlled manner.

A final management stage is not used to merely to use the Closing a Project process. In

summary, the final stage of a project will use the Controlling a Stage, Managing Product

Delivery, and Closing a Project processes.

Assuming a natural close to the project, then the “prepare planned closure” activity will be

used.

The project manager would request a product status account to ensure that all products within

the project would have been approved and that the project acceptance criteria have been met.

The Project Plan should be updated with the ‘actuals’ of this final stage.

The projects products must now be handed over to the operational and maintenance

environment, where they will be used to ultimately realize the benefits contained as stated

within the Business Case.

The project manager would updates relevant configuration item records to show that such

products have the status of ‘operational’, any acceptance records should be created or

obtained, and the Benefits Management Approach updated to reflect any products that have

already realized benefits and to include any post project activities for such benefits that have

yet to be realized.

The re-evaluate the project activity will create the end of project report to capture actual

progress and aspects such as project performance metrics and will include the Lessons Report

based upon the information contained within the Lessons Log.



In the case of premature close, then the reasons for this should be entered and updated on the

Issue Register, and if necessary any additional work may be needed to complete unfinished

products or to make them safe.

Once the project manager has determined that the project should and can be closed, then a

recommendation of such should be raised to the project board in the form of a closure

recommendation.

The final activity in any project, is the authorized project closure within the Directing a Project

process.

The project board would need to review original and updated versions of the PID, review and

approve the End Project Report, confirm any follow-on actions or loose ends, verify that the

projects products have been handed over in an appropriate manner, ensure that the Business

Case remains viable, advise that the project can now be closed, and advise those supplier

resources that these can now be withdrawn.

Okay, so now you can see how the processes work with each other. You can see that the

Starting Up a Project, Initiating a Project, and Closing a Project are usually used once per

project.

You will have noted that at the completion of the Starting Up a Project process, the Directing a

Project Process is continually used until the final close of the project.

It will not have escaped your attention that the Managing a Stage Boundary process is EITHER

used at the end of a management stage to prepare for an End Stage Assessment (ESA), OR it is

used if needed when Tolerance is forecast to be exceeded AND Corporate/Programme

Management or the Project Board request an Exception Plan – in which case the SB process is

used to create an Exception Report and prepare for an Exception Assessment (EXA).

The controlling a Stage and Managing Product Delivery processes are used continually during an

individual management stage.

So what about the 7 PRINCE2 Themes? Good question. You see, Themes are used continually

throughout a PRINCE2 project. Whereas the PRINCE2 processes describe a structured

sequence, the Themes represent project management best practice in seven key areas.



And put simply, they are applied as ‘How-To’ approaches in each of the processes.

The outline Business Case is created and used to justify investment in the initiation stage

The PRINCE2 Organization is designed and implemented

The Customer’s Quality Expectations and Acceptance Criteria are initially created as part of the

Project Product Description

A Plan for the Initiation Stage is created



Any known risks are captured and managed within the Daily Log – they are also used to make a

decision as to whether to proceed to the Initiation Stage or not.

The Daily Log is used to capture and manage any issues which include changes. The Project

Manager and the Executive/Project Board work informally to ensure pre-project progress is

under control.

As you can see from the above, I have included all 7 of the PRINCE2 Themes – and I could give a

similar example in each of the remaining PRINCE2 processes…so let’s try and summarize this in

a few diagrams:- This shows how the 7 PRINCE2 Principles are the bedrock, upon which the 7

processes are used as described and the 7 themes are applied as appropriate for each process.

And here we can see a summary of the 7 processes and themes…

Followed by the 7 processes overlaid by an example 3-stage PRINCE2 Project (remember, the

minimum is the Initiation stage plus one delivery stage – but depending upon the size,

important, complexity and risk, a project may have one initiation stage and many delivery

stages…



And to remind you, the 7 PRINCE2 Themes are applied as needed to the 7 PRINCE2 Processes:





PART TWO – The PRINCE2 PRINCIPLES, PROCESES AND THEMES

PRINCIPLES – 1

These PRINCE2 principles are based on years of experience and lessons learned from both successful projects as well as failed projects. To conform to PRINCE2, your project MUST adhere to these principles.

There are SEVEN Principles:

1. Continued business justification 2. Learn from experience 3. Defined roles and responsibilities 4. Manage by stages 5. Manage by exception 6. Focus on products 7. Tailor to suit the project environment

Continued business justification

The justification is documented in the Business Case, and this is used to drive all decision-making processes to ensure that the project remains aligned to the business objectives, and that the benefits and Business Case is viable, desirable, and achievable

The Business Case must be viable to start the project and remain viable throughout. If the Business Case ceases to be viable, the project should be changed or stopped.



Learn from experience

Everyone involved in the project should proactively seek out lessons rather than waiting for someone else to provide them. The lessons are captured in the Lessons Log when starting the project to see if any could be applied. Lessons should be included in reports and reviews including End Stage Assessments, the aim being to seek opportunities to implement improvements. When the project closes, the Lessons Report should pass on lessons identified for the use of future projects. Defined roles and responsibilities

All projects need resources with the right level of knowledge, skills, experience, and authority. These must be assigned required roles within the project. The Project Management Team structure must have these roles and responsibilities agreed plus a means for effective communication between them.

A project must have primary stakeholders, and all three stakeholder interests must be represented on the project:

• Business sponsors – ensuring that the project provides value for money • Users – those who will use the project’s products • Suppliers – they provide the project resources including the specialist team who

create the products



Manage by stages

A PRINCE2 project divides the project into several management stages – the minimum being two, the initiation stage and one delivery stage. These stages are partitions of the project with a control/decision point at the end of each - the Project Board need to approve the next stage plan before work commences.

Shorter stages give more control, and longer stages place less burden on senior management. There is no point attempting to plan beyond the horizon, as planning effort will be wasted.

PRINCE2 achieves this by having a high-level Project Plan, and detailed Stage Plans that are created for the next stage near the end of each current stage. The project is released to the Project Manager one stage at a time. Focus on products

Without a product focus projects can be subjected to “scope creep”. PRINCE2 uses Product Descriptions which are created during planning. These include the quality criteria that each product must meet. Once the products of a plan have been defined, then the activities and resources can be planned to create the products.

Manage by exception

Management by exception enables efficient use of senior management time by reducing their time and effort burden – while still having control by ensuring that appropriate decisions are made at the right level within the organization. It does this by defining distinct responsibilities at different levels for directing, managing and delivering the project with accountability at each level. The situation is escalated to the next management level (up) if the tolerances are forecast to be exceeded.

These levels of authority from one management level to the next is achieved by setting appropriate tolerances (a plus/minus allowable deviation from plan). The tolerances can be set against the six objectives and constraints for each plan. They are Time, Cost, Quality, Scope, Risk, and Benefit.



Tailor to suit the project environment

PRINCE2 is a universal project management method that can be applied to any project in any industry, organization and culture because the method is designed to be tailored. Tailoring ensures the PRINCE2 method relates to the project environment, that the project controls are adjusted to suit the project’s scale, complexity, importance, capability and risk.



PROCESSES

The Project Processes

The 7 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 a Stage Boundary

One process is used continuously from the beginning of the project until the close of the project:

Directing a Project

Each process contains a set of activities and recommended actions.



PROCESSES

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, and is the point 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 Initiation stage for the creation of the Project Initiation Documentation. The Project Mandate, issued by corporate or programme management, triggers the Starting Up a Project process, and ensures that a business requirement exists via the creation of the Outline Business Case.

SU must answer “do we have and viable and worthwhile project" and is designed to ensure that the pre-requisites for the Initiation Stage are in place. The outline Business Case is created to prove there is sufficient business justification, and the project approach is selected (how the project will deliver the end product). The decision to proceed or not, is made in the Directing a Project process.

SU provides management products that provide basic information such that the project board can make an informed choice whether to invest in the initiation stage and the creation of the Project Initiation Documentation. The Daily Log is created which is used as the project managers “diary”, and it is also used to capture and issues and known risks.

SU creates the plan for the initiation stage which covers the time and resources for the creation of the project initiation documentation, and the time and resources to prepare and plan for the second (the first delivery) stage. The Project Mandate is refined into the Project Brief leading to creation of the Project Approach. Any lessons from previous projects are identified and the Lessons Log created to log them.



The Project Product Description is created containing the customer’s quality expectations and acceptance criteria. Initiating a Project (IP)

This process is used during the first stage - the Initiation Stage and assembles the Project Initiation Documentation (PID). IP establishes solid project foundations, clarifies the reasons, benefits, risks and scope, and enables the organization to understand the work to be done to deliver the project’s products.

Other key documents include the Quality, Risk, Change Control, and Communication Approaches, and implementing the project controls. In addition, the Quality, Risk, and Issue Registers are created.

This information will be presented to the project board, who meet for the second time to authorize the project. The second Stage Plan is also created (using the Managing a Stage Boundary process). It is not until the second (delivery) stage that any specialist products are created. Both the PID and the second Stage Plan are approved or otherwise, in the Directing a Project process.

The PID sets 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. It contains a suite of management products sufficient for the level of control needed by the Project Board. The Senior User is responsible for identifying the expected benefits within the Business Case, and the Project Manager creates the Benefits Management Approach – used to define how and when measurement of the benefits will be achieved.

The project is split into several 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 authorizing the project manager to control and manage that stage.



Once the PID is signed off by the project board it is now owned by them and encourages their commitment. 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 realized are worth the time, effort, cost and risks Directing a Project (DP)

This process is used by the Project Board whose roles represent the business, users and suppliers. They are accountable for the project’s success by making 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 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 is: kept informed of stage status by regular highlight reports from the project manager, and controls via decision points

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 to either prematurely close the project, or to request an Exception Plan, which if authorized by them, will replace the existing stage plan that would no longer finish within tolerance. There is no need for “regular progress meetings”.

The project board meets to authorize the Initiation Stage, then again to authorize the project by signing off the Project Initiation Documentation.



After this they will meet at the end of each stage (End Stage Assessment), or if required, at an Exception Assessment, to agree or not that the project should continue. At project end, 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, including keeping corporate or programme management notified of project status and progress.

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 authorization as and when needed. The project board is the authority to close the project (or issue a premature close), and will ensure that the end product has been accepted and handed over, and that post-project benefits are managed and reviewed.

Managing a Stage Boundary (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 preparation work, assisted by Project Assurance, Project Support, and often, the specialist team in terms of the Team and Stage Plan.

SB is used at the end of each stage apart from the last – when the Closing a Project process is used to review the last stage progress. SB provides sufficient information to the Project Board to review the current stage, approve the next stage plan, review the updated Project Plan and Business Case to ensure continued viability, and that the aggregated risks and countermeasures are acceptable.

This process includes updating the Risk, Issue, and Quality Registers, the latter to include the quality check plan dates for the next stage products. Configuration Item Records are amended or created, The Benefits Management Approach is updated to acknowledge any Products that have gone into operational status, the End Stage Report is generated to summarize the stage and project status, and a Lessons Report is created if required.



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 Quality Management Approach need adjusting? Does the Communication Management Approach 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 summarizing 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 to proceed with the project.

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 approve the Next Stage Plan (or Exception Plan), ask for a new draft, or possibly prematurely close the project.

They will also advise the Project Manager how often they want to receive Highlight Reports in the next stage, and they will set Stage Tolerance so that “Management by Exception” can operate.

The CS purpose is to assign work via authorizing Work Packages, monitor the work progress, deal with risks and issues, report progress to the Project Board – or escalate issues, and take corrective action to ensure the stage remains within tolerance. 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.

The project manager is responsible for managing issues, and making adjustments within Tolerance if necessary.



During the stage, the project manager must ensure that the stage's products are being created, 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. Controlling a Stage (CS) – Part Two

Controlling a Stage consists of the following key activities:

1. Authorizing work packages and ensuring that they are accepted by the Team Manager or 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 or risks including an impact analysis on each

7. Escalate project issues or risks to the project board if tolerance is

forecast to be exceeded, via an Exception Report



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), these are authorized 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 keep the project manager informed of the Work Package progress, by sending regular Checkpoint Reports (or meetings) to the project manager and keeping the Quality Register updated.

The Quality Register contains planned, and eventually, actual dates of all specialist product quality checks. Once all products have been approved and authorized, 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.



Closing a Project (CP)

The purpose of this process is to provide a fixed point at which acceptance for the project product is confirmed, and to recognize that the objectives set out in the original PID have been met – or that the project has nothing more to contribute. 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 closing the project.

The objective of Closing a Project, is to have a fixed point at which the project product is accepted, and that this is confirmed, and to agree that the Project Initiation Documentation objectives have been met. This process is also used should a need arise for a premature close.

These activities need to happen:

• Verify user acceptance of products

• Ensure operations and maintenance are able to support the products

• Review the project performance against its baselines

• Assess any benefits that have already been realized, forecast the remaining

benefits and plan their review

• Capture open issues and risks with the follow-on action recommendations

Closure activities should have been included within the final stage plan, the project team can now be disbanded, and project costs should no longer be incurred. The executive should inform corporate or programme management that the project has closed.



Tailoring PRINCE2 to the project environment

Tailoring refers to the appropriate use of PRINCE2 on any given project, ensuring that there is the correct amount of planning, governance and use, of the Processes and Themes. However, adopting PRINCE2 is called embedding.

The Principles are universal and always applied and are never tailored. The Themes have the projects environmental and project factors built into the project’s controls, and an organization’s policies and standard are captured within the relevant PRINCE2 strategy document. PRINCE2 may be to use local terminology terms and language variances.

Product Descriptions may be revised for the management products along with the PRINCE2 role descriptions. PRINCE2 can be used whatever the project scale, industry, complexity, culture or geography.

Tailoring does not consist of omitting elements of PRINCE2, but adapting the method to external factors. The objective is to apply a level of project management that does not overburden the project, but provides an appropriate level of control given the external and project factors.

All PRINCE2 processes and their activities must be used, although responsibilities for performing the activities may change.

Aspects of PRINCE2 that may be tailored are:

• The customer/supplier environment including whether the project is part of a

programme • Lifecycle models and project management bodies of knowledge • Project scale and people verses roles including options for applying people to roles

and vice-versa



THEMES

Themes describe aspects of project management that need to be used continually throughout a project. They could be considered as “approaches”, since, for example, the Risk Theme advises how risk management is to be used and applied. The Themes are:

Business Case

The Business Case sets out WHY the project is needed, and is used to judge whether the project is viable, desirable and achievable. It evolves from the reasons given in the mandate as an outline version, and the detailed Business Case is refined and contained within the PID. The business case is used as the driving force behind the project. It should be reviewed at a minimum, at the end of each management stage.

If a satisfactory business case does not exist, then the project should not be started. If business justification is valid at the start of a project, but disappears during the project, then the project should be changed or stopped. The Business Case justification is based upon the estimated costs, risks and the expected benefits. When projects face risks or change, these should be referenced to the Business Case because the project is only a means to an end – not the end itself.

The Senior User is responsible, and accountable to Corporate/programme Management for specifying the desired benefits, and for subsequently realizing them (some or all may be after project closure) Whereas the Executive is responsible for ensuring that these same benefits are aligned with corporate objectives, are realistic, and provide value for money.



The Organization Theme (Part One)

The PRINCE2 project management structure is based on a customer/supplier environment. The organization structure consists of 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.

PRINCE2 assumes a customer/supplier environment – the customer specifies the desired result (and probably pays for it, and a supplier who provides the resources to deliver that result. 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 representation from the business, user, and supplier interests at all times. 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 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 project board Executive will involve and consider advice and opinions of the other two roles, but ultimately, always has the authority to take the final decision.



There are 4 levels of management: Corporate/Programme Management – responsible for commissioning the project Directing – The Project Board is responsible for overall direction and management of the project Managing – The Project Manager is responsible for day-to-day management within the Project Board constraints Delivering – Optionally, a Team Manager may be appointed – responsible for planning specialist products and managing the specialist team

The Organization Theme – Part Two

The Senior User role represents those who will either use the final product, achieve an objective for them, use the result to deliver benefits, or they will be impacted (hopefully in a positive way!), by the project outcome. As with the other roles, this one must have the authority to act.

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 and must be able to support technical integrity of the project.

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 organization. It is recommended that project board members should remain with the project until its close whenever possible.



However, as each Stage progresses, those who fill the roles may need to be modified.

The Organization Theme – 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, authorizing 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 – but supported by Project Assurance and Project Support.

There are several optional roles which may be filled - however, if no one is available then the project manager must perform these roles themselves. 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 team manager role may optionally be carried out by another individual if required. By default, the project manager fulfills this role. For example, if the team size is too large, the specialist nature of the products is unfamiliar to the project manager, where the team is dispersed over a large geographical area, or where a third party organization 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.



The Progress Theme – Part One

The purpose of the Progress Theme is to establish mechanisms to monitor and evaluate actual achievements against planned objectives so that a forecast can be made for forecast objectives and continued viability. Progress is the measure of the achievement of the objectives of a plan, and it can be measured at Work Package, stage or project level. Controls are built into the project to ensure that progress is monitored and to detect problems early and react, and that those plans are regularly reviewed and updated.

There are many 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 specific 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 within the context of Management By Exception. Tolerance can be applied to several aspects of the project including; time, cost, scope, quality, risk, and benefits.

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.

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.



The Progress Theme – Part Two

Progress controls ensure that each level of the project management team can:

• Monitor progress • Compare the level of achievement with plan • Review plans and options against future situations • Detect problems early and detect risks • Initiate corrective action

• Authorize further work

For Project Board and Project Manager levels, the many controls allow them to provide appropriate authorizations, receive progress updates, and manage exceptions and changes.

Work Package tolerances are set by the Project Manager, and if forecast to be exceeded, the Team Manager raises an issue so that the Project Manager can advise of any corrective action.

Stage level tolerances are set by the Project Board, and if forecast to be exceeded, the Project Manager raises an Issue, and sends the Project Board an Exception Report. The Project Board may then request an Exception Plan which is reviewed by them at an Exception Assessment to approve it or otherwise.

Project-level tolerances are set by Corporate or Programme Management, and the Project Board must refer to them should project tolerance be forecast to be exceeded.

The Risk Theme – Part One

A risk is an uncertain event that, should it occur, will influence the achievement of objectives. It consists of a combination of the probability of a perceived threat or opportunity occurring, and the size of its impact on objectives. Every project has risks since projects cause change and change results in uncertainty – hence risk. The project manager is responsible for ensuring that risks are identified, recorded and regularly reviewed.



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.

Each risk should be allocated a risk owner who is responsible for managing the risk, and a risk actionee, who is responsible for carry out the risk actions (they may be the same person). The project board and project manager may themselves own specific risks. All risks and their details are entered on to the Risk Register. 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. The proximity of each risk should be considered – expressed as a time from today, or a specific date. This is helpful in prioritizing risk actions and determining the severity of a risk due to the time frame when it actually might occur.

Every project should have a Risk Management Strategy, describing the procedures for capturing and registering risks, and a means of control – the Risk Register, which is used to capture and maintain information on identified threats and opportunities.



The Risk Theme – Part Two

The Risk Management procedure is split into FOUR main steps:

1. Identify. Identify the specific objectives that are at risk – and to formulate the Risk Management Approach, capture the risks and place on the Risk Register

2. Assess. Estimate the probability, impact, proximity and severity of each risk 3. Plan and Prepare responses to the risks – Avoid, Reduce, Fallback, Transfer, Share,

Accept and for opportunities, Exploit, Enhance, Share, Reject, for opportunities 4. Implement Carry out the risk/opportunity actions, monitor and report 5. Communicate Ensure internal and external communication on the aggregated risks.

Risk or opportunity Impact should be considered under the following headings: Time, cost, quality, scope, benefit, and people/resources. Once a plan is signed off, then monitoring and reporting can take place. This will normally consist 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. Risk management 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 authorize 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, authorizing and accepting Work Packages

2. Examining project issues, as part of management by exception

3. When closing the project – operational risks that need to be managed by others after

closure.



The Quality Theme

The Quality Theme defines the approach to ensure that the project’s products meet business expectations and will enable the desired benefits to be realized. It addresses the quality methods and responsibilities for the specification, development, and approval of the products as well as for the management of the project.

The focus on products principle is central to PRINCE2 approach to quality because it provides an explicit understanding of what the project will create and the quality criteria against which the project’s products will be assessed. Capturing and acting on lessons contributes to the PRINCE2 quality approach.

Project and hence stage costs and timescales can only be estimated after establishing the quality criteria for the products and the quality management activities that are required. The Quality Management Approach is created, describing how quality is to be achieved, and this should include responsibilities for quality and any special standards that will need to be met.

The Quality Register is set up and used to capture the planned, and eventually actual, dates, of all specialist products quality checking activities. As such it may be a progress tool. During the creation of all plans, and using the Product-Based Planning, Product Descriptions are written in close consultation with the users, and quality criteria agreed for each product. The Stage Plan must include information on 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 (Executing a Work Package). When each product has been created, it is submitted to the agreed Quality Check laid out in the Product Description. This may be an informal Quality Check – or a Formal Quality Review. The former is used when the quality measurements are a simple Yes/No, the latter when the criteria are more subjective.



Once passed, the product is approved and usually given to Project Support/Configuration Management. The Quality Log should be updated with actual dates of the Quality Check.

The Plans Theme – Part One

The Plans Theme makes the point that a plan is a document - not, for example, just a scheduled diagram (Gantt Chart, etc.) Without a plan there is no control. 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. The Plans Theme provides a framework to design, develop and maintain the project’s plans.

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. Progress is measured against a set of baselined plans. Each plan needs approval at the appropriate level.

PRINCE2 recommends three levels of plans to reflect the needs of the different levels of management involved:

1. The Project Plan – created by the Initiating a Project process 2. Stage Plans – The Initiation Stage Plan is created by the Starting Up a Project process,

and remaining delivery stage plans are created by the Managing a Stage Boundary process

3. Team Plans – these are optional and are created by the Managing Product Delivery process

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, authorize 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.

The Plans Theme – Part TWO

The Benefits Management Approach covers activities both during and after the project (post-project benefits reviews), and may therefore be part of a corporate or programme plan.

Product-Based Planning

This is used first to identify the products of a plan, then the activities and resources are considered that are needed to create that product. A product is anything that the project must produce in some way and is described using 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 the Project 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)



The Plans Theme – Part THREE

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.



The Plans Theme – Part FOUR

The Product Breakdown Structure.

There are two other diagramming methods that can be used to represent the Product Breakdown Structure, as a mind map diagram or by an indented list:

The Plans Theme – Part FIVE

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.

Roast Chicken



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. The Plans Theme – Part SIX

Intermediate Integration Products

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 sub-products 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. The project has no control or influence over such Products.

Prepared Fruit Punch



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.

The Plans Theme – Part SEVEN

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 will be applied to the finished product

5. The people or skills needed to produce/create/procure the product, review

the product (via the quality review or quality check), and the person with the authority to approve the product.

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.



The Plans Theme – Part EIGHT

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. 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 helps the planner to identify dependencies between one product and another and any opportunities to develop some products in parallel.

The Change Theme – Part One

Change is inevitable during the life of a project; hence the systematic approach to the identification, assessment and control of issues that could result if change is required. Anyone may raise an issue at any time, therefore a common approach to issue and change control is needed.



An issue can be:

• General problem or concern • Request For Change a proposal for a change to a baseline

• Off-Specification Something provided by the project, but currently/forecast not to be provided

A pre-requisite of effective issue and change control is the establishment of a configuration management system that baselines the project’s products and ensures that correct versions are delivered to the customer.

The Project Board may elect themselves as the authority to deal with changes, or delegate that responsibility to a Change Authority, including agreeing a change budget to analyze and implement such changes.

The aim of issue and change control procedures is not to prevent changes – but to ensure that the relevant authority agrees every change before it takes place. It is recommended that the Project Board should include representation from the business, user, and supplier interests at all times. The change Theme identifies, assesses and controls any potential and approved changes to baselines.

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, that is responsible for applying this technique within the Controlling a Stage process. When an issue is raised, it should be entered into the issue Register, categorized according to the type of issue, and a copy sent to the author to advise its receipt and entry into the issue log.

The Change Theme – Part Two

The issue and change control procedure includes; capturing and categorizing the issue and placing it on the Issue Register, carrying out an impact analysis on the project objectives, Business Case, and project risks, identifying, evaluating and recommending options, approve, reject or defer the issue option, and if appropriate, implement the corrective action.

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.

The Issue Register 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 Register should always be inspected when examining an issue.

The author of an issue should include their opinion of the Priority and Severity of the issue (if a RFC or Off- Spec:), 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.

The Change Theme – Part Three

Configuration Management

Within the context of a project, Configuration Management can be considered as version control. Configuration Management is used to manage the 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 and Registers. 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 organization – usually supplied as part of Project Support, 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.

Configuration Management and Change Control must work very closely together. The Configuration Control Approach is created in the Initiating a Project process and describes the way that change and configuration management is to be applied and used for the project and its products.

This Approach 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.

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 authorized 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.

The Change Theme – Part Four

When a specialist product passes its quality check and is approved, it moves from the draft to approved status. Where appropriate, the Configuration Management holds master copies of products. They also control 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.

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).

Status accounting. Configuration Management maintains full records of the status of all products and a full history concerning each.

Verification. Configuration Management 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. Two important guidelines: If a product is to be changed, its product description should also be checked to see if it too, needs to be changed – and – 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. Appendix A.

Product Description outlines for the defined management

products, split into the following groups:

BASELINE DOCUMENTS BASELINE DOCUMENTS RECORDS REPORTS Benefits Management Approach Project Brief Configuration item Records Checkpoint Report

Business Case Project Initiation Documentation Daily Log End Project Report

Communication Management Approach Project Product Description Lessons Log End Stage Report Change Management Approach Work Package Issue Register Exception Report Quality Management Approach Plan Quality Register Highlight Report Risk Management Approach Product Description Risk Register Issue Report Lessons Report

Product Status Account



Now you’ve sampled my ‘PRINCE2 In 60 Seconds Flat’ Guide – are you ready for the NEXT STEP?

Hop on over to


…….is waiting for you….

…and check out the great deal on preparing for your PRINCE2 Training Course….streaming video coaching in preparation for your Accreditation as a PRINCE2 Practitioner!




Now you’ve sampled my PRINCE2 Walkthrough and Roadmap, you are now one of the few folks

out there who are taking their path to PRINCE2 Practitioner seriously…

Good Luck on your PRINCE2 journey…and check out the great deal on preparing for your

PRINCE2 Training Course – with my PRINCE2 2017 Masterclass:

https://www.projex.com/prince2-masterclass/


Documents

PRINCE2 walkthrough and Roadmap - projex.com · Step By Step Guide PRINCE2 walkthrough and Roadmap Dave Litten