P. 1
PRINCE2 Process Map Walk through IXL Group

PRINCE2 Process Map Walk through IXL Group

|Views: 22|Likes:
Published by sudhircerin
PRINCE2® Practitioner
Process Model Walk through
PRINCE2® Practitioner
Process Model Walk through

More info:

Published by: sudhircerin on Jan 19, 2014
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/23/2015

pdf

text

original

Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 1
















PRINCE2
®
Practitioner
Process Model Walkthrough



COPYRIGHT NOTICE
This document is the copyrighted intellectual property
of ILX Group plc and may not be copied,
disassembled or in any way modified
without the express and written permission
of ILX Group plc.




Version: 2.1.0
05/02/10










PRINCE2® is a Registered Trade Mark of the Office of Government Commerce
in the United Kingdom and other countries.
Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 2




PRINCE2 Process Map – Walkthrough - interface
Before we get started, we’ll take a few moments to explain the interface for the walkthrough. The first
thing you will have noticed is that the page is wider than usual, this is deliberate and is intended to
provide the maximum amount of viewable space for the presentation. As a consequence the subtitle
function has been disabled. If you would like a printed version of the session subtitles, you can print a
copy by clicking here. A hard copy of the process map can be printed at the end of the presentation. If
you would like to print a copy before you begin, then click here.

You may have noticed that the page control functions have been nested to save space. To view these
controls click here. The controls can be re-nested at any time.

The presentation is extremely comprehensive and lasts approximately 30 to 40 minutes. If you are re-
visiting the presentation and wish to jump to a particular process, you can do so by selecting the
process title from this drop down list.

PRINCE2 Process Map – Walkthrough
A PRINCE2 project has a beginning, a middle, and an end. The beginning includes starting up the
project and the definition and planning of the project. The middle is the exciting part, building the
specialist products and creating the output that will eventually deliver the benefits, in other words,
getting the work done. The end is the finishing off where the output is handed over to the Customer,
when all loose ends are tied up and the success of the project, itself, is measured.

Legend
We have called the beginning ‘getting going’ and it is represented with green. This includes the
processes, arrows denoting where management products or other items go into or out of the
processes, and any explanatory writing within the grey rectangles.

The middle section of the project, ‘producing products’, is represented with blue. This covers the
building of the products which make up the output and is the subject of the project plan.

The end or ‘finishing off’ section of a project is represented with orange. As part of the final
management stage, it is necessary to complete the processes and activities of the project, obtain
customer acceptance, and tie up all loose ends by bringing the project to an end in a professional
manner.

The grey boxes in the main represent Management Products. Those without the ‘turned down page
corner icon are non Management Products. Either style of box may contain text in different colours.
The colour references the source of the information. For example green text would indicate ‘getting
going’ processes as the source. Red is used to denote anything related to issue or exception
processing. Rectangles with multi-coloured text have source information originating from different
parts of a project. That concludes the introduction so let’s begin building the PRINCE2 map.

Corporate Management
The first element to introduce is Corporate or Programme Management. This is the PRINCE2 term for
the senior management team of an organisation responsible for planning and implementing projects.
Projects may be stand alone or contribute to a program of linked projects.

Although not part of the project management team, Corporate or Programme Management starts up a
PRINCE2 project and will also need to be informed when it is finished They will also need to be kept
appraised of progress throughout the project by the executive on the Project Board.

We will now introduce the 7 main processes.

Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 3



Starting up a project
The first process is Starting Up a Project. This includes the activities required to start the project on a
strong, viable and worthwhile footing.

An Executive and Project Manager are appointed along with an appropriate team to run the project.
Any previous lessons about similar projects are captured. An outline Business Case is prepared based
on the project mandate and the expected benefits documented. An appropriate project approach is
decided and a Stage Plan to complete the initiation stage is compiled.

Planning is carried out at various times throughout a project. The Plans Theme provides a framework
to design, develop and maintain all the Project’s Plans. This framework supports all three levels of
plan whether at Project, Stage, Team and any Exception Plans at stage or project level.

During Starting up a Project, the Project Manager will use the planning steps to create the Stage Plan
for the initiation stage and then during initiation the Project Plan and similarly, near the end of each
subsequent management stage, to plan the next management stage.

Planning
During Starting up a Project, the Project Manager will use the Planning Process to plan the Initiation
Stage and then similarly, near the end of each subsequent Management Stage, to plan the next
Management Stage.

So let’s take a look at planning in a little more detail. There are seven sub-processes in planning and
each is used on an iterative basis, as often as required, to form original plans or amend plans as
circumstances dictate. The Planning Process is called from many other sub processes throughout the
life of the project.

There are seven steps in the in planning procedure. The steps involved are the same for all three
levels of plan, i.e. the Project Plan, Stage Plan and optional Team Plan. Several iterations are
normally needed to produce an acceptable plan, so each step is used as much or as little as required
to achieve a working plan.

‘Design the plan’ is the first step, where decisions on the presentation and layout of plans, planning
tools, levels of plan, allowances and monitoring methods are established before any planning takes
place.

It is within the ‘define and analyse the products’ step that the product based planning technique may
be used to produce four distinct management products. These are:

• a Project Product Description of the final product or Output,
• a Product Breakdown Structure for the project, breaking the project into its constituent
products,
• Product Descriptions for each product as necessary
• and a product flow diagram showing the order of creation of the products in order to complete
the project.(or stage).

The step ‘Identify activities and dependencies’ uses the Product Flow Diagram to identify the activities
required to create each product in the correct order. Dependencies between activities are established
in order to schedule and control the work. The output of this step can be displayed as an activity or
precedence network.

‘Prepare estimates’ identifies resource types and estimates the effort required for the activities.
Elapsed times can be estimated within this step. The output of this step can be displayed as a critical
path network showing the timescale of the plan and float of each activity.

‘Prepare the schedule’ is the application of resources to the activities. Resource smoothing and
levelling can be applied here to produce a suitable schedule. It is often displayed as a Gantt Chart.


Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 4




The ‘Analyse the risks’ step will typically run in parallel with the other steps of planning. Once a plan
has been produced, it should be considered a draft until any risks inherent in the plan have been
identified and assessed. If necessary the plan should be modified.

‘Document the plan’ is the final step to complete in planning. Narrative needs to be added to explain a
plan. This includes any constraints, external dependencies, assumptions risks and any applicable
tolerances.

Directing a Project
The Directing a Project process is owned by the Project Board. This group of decision makers
represent the Customer, Supplier and the Business interests in the project. The Project Board
manages by exception, monitors via reports, and controls the project at key decision points, delegating
the ‘day to day’ project management to the Project Manager.

Initiating a Project
The Initiation Stage involves the definition and planning of the project. Before any work can be done to
produce the output, a solid baseline on which to judge progress should be created before committing
to significant spend.. The key product of this process is the Project Initiation Documentation which
defines the what, why, where, who, how, when and how much.

Managing Stage Boundaries
The Managing a Stage Boundary process in which the Project Manager produces the information on
which the Project Board will take any decisions, including whether to continue the project or not. This
process is carried out towards the end of the initiation stage and each subsequent management stage.

Based on the size and risk of a project and commitment to resources, the Project Board will break a
PRINCE2 project down into a suitable number of stages – initiation and one or more management
stages. The project manager will contribute to these decisions.

Controlling a Stage
Controlling a Stage is the set of activities which enables the Project Manager to execute day to day
management and control of each of the management stages of the project in order to keep them
within tolerance. In essence this is controlling the teams who are the specialists producing the projects
products.

Managing Product Delivery
Managing Product Delivery is the process executed by the teams to create and deliver the planned
products. Most of the project work is done here to ensure that products are delivered to the right
quality and within the constraints of cost and time.

Closing a Project
Closing a Project is the final process in the method. It exists to bring about a professional and
controlled close to any project, whether the natural end or as a result of a premature closure. The
Project Board should be assured that all loose ends have been tied up and the project is finished off
correctly. It provides a fixed point at which acceptance of the project output is confirmed.

That concludes our overview of the seven PRINCE2 processes. We will now build the main inputs and
outputs relevant to each of these processes and activities.

Starting up a Project
A project begins when Corporate or Programme Management appoints an Executive and hands over
the project mandate. The Executive will appoint a Project Manager who will create the Daily Log.

Project Mandate
The Project manager and the Executive will review previous lessons and enter these into the Lessons
Log. These may help with the delivery of the project – for example there may be lessons from previous
projects which would help the Executive to develop a more robust Business Case, or affect the Project
Plan.
Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 5





The Executive, assisted by the Project Manager are jointly responsible for the design and appointment
of the rest of the project team.

In parallel with these activities, the Project Manager will expand the Project Mandate. An outline
Business Case is prepared along with the Project Product Description along with the project approach.

Once these are understood the project definition can be finalised and the Project Brief assembled.

The project Brief contains the project definition, the outline Business Case, the Project Product
Description, project team structure and the project approach.

The final activity that the Project Manager will perform during Starting Up a Project is to produce an
Initiation Stage Plan.

In order to accomplish this, the Project Manager will use the 7 planning steps, as required, to design
the Initiation Stage Plan.

In PRINCE2 projects, the Executive owns the Business Case. Therefore, during Starting up a Project,
the Project Manager will liaise closely with the Executive on its development. The Project Manager will
also work with the Senior User on the definition of requirements and business benefits, and with the
Senior Supplier to define the project approach.

So, the outputs of Starting Up a Project are, a Lessons Log, the Stage Plan for initiation, the Project
Brief, including a project management team structure, Project product description, project approach,
outline Business Case. Remember, any issues or risks will be recorded in the Daily Log during
Starting up a project and transferred into the appropriate register if the project is approved to go into
the initiation stage.

The Project Manager will present the Project Brief and Stage Plan with a trigger ‘Request to initiate the
project’ at the first meeting with the Project Board. It is at this meeting that the Project Board will
decide if the investment required to complete initiation is worthwhile.

Assuming the answer is yes then the Project Board will issue the trigger ‘authority to initiate a project’
and advise the corporate body via the trigger ‘initiation notification’

Initiating a Project
The Project Manager will commence the initiation stage, the first management stage of a PRINCE2
project.

During Initiation, The Project Manager will expand the information established in Starting Up a Project
and create a Project Initiation Documentation.

During Initiation, it is necessary to clearly establish strategies for Risk, Configuration Management,
Quality and Communication. These could be regarded as four sets of rules for this project. The project
controls will also be established and a Project Plan will be created using the Plans theme guidance.
The Business Case will be refined with the costs, time and risks from the project Plan and any other
relevant details to enable ongoing viability questions to be answered.

The seven activities of Initiating a Project should be started when appropriate and it is likely that they
will have to be revisited as the Project Plan strategies and Business Case are developed.

However, it makes sense to at least develop the four strategies first as these will affect the Project
Plan and Business Case.




Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 6



So let’s get on with it and develop the Risk Management Strategy and create the Risk Register.

The Configuration Management Strategy can then be created which will include defining the authority
levels for approval of change and establishing whether or not a change budget will be used. The
Issue register will also be created.

The Quality Management Strategy and Quality Register are developed which will lead us to the
Communications Management Strategy. This will include any stakeholder analysis and consultation
about their information requirements.

Using the planning steps the Project Plan is prepared. This is usually done as a group activity with the
team and with information from the Project Brief, Lessons Log, Risk Register, Issue Register and
strategies which will all affect the plan.

In conjunction with the team the Project Manager will develop the Project plan. This will involve the
Plans theme and in particular the product based planning technique. As the plan is developed the
method of controlling it will also become clear, for example the number of stages to be used, the type
and frequency of communication between the team, issue management and so forth,

The controls will be documented as part of the Project Initiation Documentation as will the Project
Plan.

Now that the Project Plan has been developed the contents of the Business Case can be refined
based on the work completed in ‘Starting up a Project’ and the costs and timescales from the Project
Plan. A very important part of this activity is to develop the Benefits Review Plan.

The final activity now is to Assemble the Project Initiation Documentation. This requires all the work of
initiation to be compiled. Not that this relates to a single document, rather it is a set of information
upon which the Project Board and Project Manager will make decisions. Each part will be kept under
configuration management and updated at least at the end of each stage.

As we near the end of the stage a trigger ‘Stage Boundary Approaching’ is generated and this prompts
the Project Manager to produce the Stage Plan for the next stage using the process ‘Managing a
Stage Boundary’. This will also include the production of an End Stage Report if necessary. We’ll
have a look at the work of ‘Managing a Stage Boundary in more detail later.

When this is all completed the Project Initiation Documentation, Stage Plan and Benefits Review Plan
along with the trigger ‘request to deliver a project’ will be sent to the Project Board where they will
make a decision in the activity ‘authorize the project’ and ‘authorize a Stage or Exception Plan’

Assuming all is well the project Board will authorize the project and the Stage Plan for the next
delivery stage. They will also keep the ‘Corporate body’ advised of the decision.

In the event of problems the Project Board can direct the Project Manager to close the project
prematurely. We’ll look at this a little later.

Directing a Project
Once the Project Board have given the authority to proceed with the initiation stage a very important
activity comes into play called ‘Give ad hoc direction’. This enables the Project Manager and the
Project Board the mechanism to communicate on both a formal and informal manner through the
trigger ‘Project manager request for advice’, and also enables the corporate level to advise the Board
of new matters through the trigger ‘Corporate advice and decisions’.

This completes the ‘Getting Going’ section of the project denoted by green in our process map.

So, following authorisations from the Project Board to proceed with the project and the first delivery
stage the exciting part of managing a project begins – getting the work done and building the
products that form the project outcome.

Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 7


The team must be fully focused on the delivery of the products within the stated tolerances of cost,
time and quality. This involves using three processes.




The ‘Controlling a Stage’ process, which forms the main part of the Project Manager’s work and
provides the direction for the day-to-day management of the stage and the overall project.

‘Managing Product Delivery’, which is where the teams will undertake the work itself, and ‘Managing a
Stage Boundary’, this prepares for the End Stage Assessment with the Project Board.

Managing Product Delivery and Controlling a Stage
Controlling a Stage consists of eight activities which are bound into a cycle of Work Packages,
Monitoring and Reporting, and Issues.

Let’s consider the interaction between Controlling a Stage and Managing Product Delivery in a little
more detail.

Firstly, the work packages group has three activities – ‘Authorize a Work Package’, ‘Review Work
Package Status’ and ‘Receive Completed Work Packages’. Basically, the Team Manager and the
Project Manager will discuss the content of the Work Package and the Team Manager agrees to
undertake the work in the manner described in the Work Package. This is the first activity in
‘Managing Product Delivery’, namely ‘Accepting a Work Package’.

As the work progresses in ‘Execute a Work Package’ the Team Manager will send Checkpoint Reports
to the Project Manager who will review these in ‘Review Work Package Status’.

Another important activity that takes place during ‘Executing a Work Package’ is quality checking. As
the products are built they will be checked in accordance with the Product Description and the Quality
Register.

When the work is completed the Team Manager will advise the Project Manager via the trigger
‘Completed Work Package’.

The Project Manager will consider this in the ‘Receive Completed Work Packages’ activity and will
ensure all the work has been completed prior to signing off the Work Package.

Whilst all this activity is proceeding the day-to-day monitoring and reporting must be considered via
two activities – ‘Review Stage Status’ and ‘Report Highlights’. ‘Review Stage Status’ requires the
Project Manager to look at the ‘big picture’ of the project. This means looking at what has happened
versus what was expected, reviewing the next chunk of work and making sure that risks and issues
are under control and, if necessary, triggering corrective action.

Periodically, the Project Board will need to be informed of progress. At the frequency defined by the
Board, the Project Manager will issue a Highlight Report as described in the ‘Report Highlights’ activity.

The final activity group associated with issues involves capturing the issue or risk. Issues that can be
managed informally should be noted in the Daily Log. Otherwise they should be entered into the Issue
Register and analyzed further.

Risks should be entered into the Risk Register. Any action required to maintain the project schedule
within tolerance is taken via the ‘take corrective action’ activity. This can involve modifying an existing
Work Package or creating a new one.

If the issue or risk cannot be resolved within tolerance then it will need to be escalated to the Project Board
via an Exception Report using the ‘Escalate Issues and Risks’ activity and the trigger ‘exception raised’.

At some time in the Stage the Project Manager will be aware that the end of the stage is approaching
– this will generate the trigger ’stage boundary approaching’
Process Model Walkthrough

PRINCE2™ Practitioner
© 2003 ILX Group plc 8



Managing a Stage Boundary
By controlling the start and finish of each stage, specific attention can be given to whether the stage’s
products have all been completed within tolerance, whether the remaining products are still required
and whether the Business Case remains valid. This is a key control process for the Project Board and
incorporates all the key aspects of ‘Directing a Project’. The Project Board undertakes this work in
‘Directing a Project’ and in order to prepare for the End Stage Assessment the ‘Managing A Stage
Boundary’ process is triggered by ’stage boundary approaching’.

The objectives of the process are to:

Assure the Project Board that all products in the current Stage Plan have been completed as defined.

Provide the information needed for the Project Board to assess the continuing viability of the project.

If a phased handover of products occurred during the stage, confirm that user, operational and
maintenance acceptance has occurred and follow-on actions/ recommendations for these products
are in place.

In the normal course of events four activities will be completed leading to the main outputs which are
an End-Stage Report, a Stage Plan for the next stage, updated Project Initiation Documentation and
Benefits Review Plan and a Request to approve next Stage Plan.

In the event that a stage or project is in exception then it is likely that the Project Board will ask for an
Exception Plan to be produced. This will be in response to the Exception Report and will be triggered
by an Exception Plan request.

The Project Manager will produce an Exception Plan’ and update the Project Initiation Documentation
as appropriate.

The outputs of ‘Managing Stage Boundaries’ feed into the ‘Directing a Project’ process, in particular
‘Authorize a Stage or Exception Plan’.

The project Board will approve the next stage or Exception Plan and from now until the end of the
stage the management of the project will involve cycling through the ‘Controlling a Stage’ and
‘Managing Product Delivery’ processes as work packages are authorized and work is undertaken by
the Team Managers and their teams.

As the work in the final stage of production nears completion a trigger called ’Project End
Approaching‘ is issued from ‘Controlling a Stage’ and the ‘Closing a Project’ process will begin.

Closing a Project
The products are handed to the customer and the operational support team. The benefits review plan
is checked to make sure it contains sufficient detail to enable the benefits to be measured and realized
after the project is closed.

Lessons will be examined and a Lessons Report will be included in the End Project Report. Any
outstanding work will be included in the End Project Report as a follow-on action recommendation.

The Project Initiation Documentation with the updated Business Case, the End Project Report and the
Benefits Review Plan will be sent to the Project Board along with a ‘Closure recommendation’.

The Project Board will confirm that the project can be closed and approve and issue the reports to
interested parties, finally issuing a ‘Closure notification’.

In the event of a premature close the Project Board will issue a trigger ’premature close’. The activities
within ‘Closing a Project’ are still undertaken with the exception that ’Prepare planned closure’ is
replace by the activity ‘Prepare premature closure’.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->