Project Objectives
Specification
• A project should be delivered:
– on time
– within budget
– to specification
scope and quality
Completion
Start
Cost
Time
PRINCE Introduction 1
Typical Problems with Projects
• Poor initiation
• Planning insufficient
– Poor estimation
Inadequate resources and unrealistic deadlines
– Poor coordination
• Goals/Direction unclear
– Goals & Resources changed
• Communications Breakdown
– Inter-Departmental Conflicts
– Team Members uncommitted
• Quality problems
• Lack of control
PRINCE Introduction 2
PRojects IN Controlled Environments
• Standard project management method
• Used widely in UK, increasingly internationally
• Registered trademark but public domain
• History
– Pre-PRINCE
PROMPT created by Simpact for IBM in 1975
PROMPT 2 adopted for government information systems projects in 1979
Developed into PRINCE in 1989 for all government information systems
– PRINCE 2
Released October 1996 as a generic method suitable for all projects
Last updated 2009 – now used and examined worldwide by APMG
PRINCE Introduction 3
Why have a Project Management Method?
• Helps to
– Reduce the risk of failure
– Increase the chance of success
• By defining a BEST PRACTICE approach
Best
Practice
– based on practical experience and research
– enables standardisation of approach and terminology
for project managers, team members, customers, suppliers, and contractors
– provides a basis for improvement
within the industry sector, the organisation, and generally
• Public domain standard ensures competitive supply of
contractors, consultants, and trainers
– examination and accreditation schemes
PRINCE Introduction 4
What does PRINCE do?
• Focuses on the Business Case for the project
• Ensures a solid foundation with a thorough Initiation
• Helps divide the project into manageable and controllable
stages
– using product-based planning
• Defines an organisation structure for project management
– customers and suppliers
– authority and reporting levels
• Provides control mechanisms
– quality
– changes to products and plans
• Scaleable and adaptable to different project circumstances
– through a comprehensive Process Model
PRINCE Introduction 5
PRINCE “best” practice principles
• Projects are finite
– definite start and end
• Projects always need to be managed
• Commitment from all must be achieved by
– clear objectives
– clear purpose
– clear mechanism
– clear responsibilities
PRINCE Introduction 6
PRINCE: definition of a Project
“A management environment which is created for the
purpose of delivering one or more business products
according to a specified business case”
Characteristics of projects:
– uniqueness
– pre-defined result at pre-specified time using pre-determined resources
– temporary organisation
– organisation structure to manage the project
– a business context
– maybe stand-alone, part of a sequence of related projects, or part of a
programme or strategy
PRINCE Introduction 7
Project and Product Life Cycles
Idea
Product
Feasibility Study
Project Start Up
Project Initiation
Life
Specification
Design
Change over
Project
Life
Cycle
Scope of
PRINCE
Construction
Test
Cycle
Use
Scrap
PRINCE Introduction 8
PRINCE components and processes
Organisation
Business
Case
Plans
Directing a Project
Directing a Project
Controls
Starting
Startingup
up
aaProject
Project
Initiating
Initiating
aaProject
Project
Planning
Planning
Management
of Risk
Controlling
Controlling
a
a Stage
Stage
Managing Stage
Stage
Managing
Boundaries
Boundaries
Closinga a
Closing
Project
Project
Change
Control
Managing
Product
Delivery
Quality in a Project
Environment
Configuration
Management
PRINCE Introduction 9
Programmes
“A programme is a portfolio of projects selected, planned, and
managed in a co-ordinated way and which together achieve a set
of defined business objectives.”
“Programme management methods and techniques may also be
applied to a set of otherwise unrelated projects bounded by a
business cycle.”
•Examples of programmes are:
– building new hospital, building a new railway line, producing a new
drug or product
all contain a multitude of sub projects
•PRINCE does not cover programme management in detail
– but makes some suggestions on its interface with projects
PRINCE Introduction 10
What PRINCE does not describe
• The actual work or techniques of the project
• People management techniques and ‘soft’ issues
– but formal frameworks provided
• General planning techniques (e.g. PERT, CPA)
– but integrates well with these
• Specific estimating techniques
• Detailed risk analysis and management techniques
– but risk control embedded in PRINCE approach
• Organisation-wide Quality Management Systems
• Detailed financial justification aspects of projects
• Procurement and contracting
– although these can be managed using PRINCE
• Programme management
PRINCE Introduction 11
Formal Project Initiation
user
En
PM
Project Initiation Document:
Background, Definition,
Assumptions, Business Case,
Organisation , Project Plan, Controls,
Quality Plan, Communication Plan,
Exception process, Risk Log,
Contingency Plans, Filing Structure
exec
Approval of PID
PRINCE Introduction 12
Vision Statement
• Concise statement that the summarises the long-term purpose and intention
• Balanced view that satisfies diverse stakeholders
• Idealistic but grounded in reality
Can use the following keyword template
• For [target customer]
• Who [statement of the need or opportunity]
• The [product/system name]
• Is [a product category]
• That [key benefit, compelling reason to buy or use]
• Unlike [primary competitive alternative, current system, or current business
process]
• Our product/system [statement of primary differentiation and advantages of new
product/system]
PRINCE Introduction 13
Yorkies vision statement
• For customers and potential customers who want to rent load- carrying
vehicles, the Internet booking system is an information system that will
enable Internet users to check the vehicle availability, cost, and driver
availability for rentals; book and make credit card payments. This system
will hold details of vehicles, drivers, depots, and maintain a history of
vehicle movements. The system will manage the invoicing and payments
of account customers. The system will increase booking revenue by 20%
and decrease administration costs by 10% in the first year of use. Unlike
the current manual booking process our system will enable customers to
obtain immediate feedback on availability and book one-way hires.
PRINCE Introduction 14
Boundaries of systems / projects
Business system
IS system
IT system
PRINCE Introduction 15
Project Scope - Context Diagram
Payroll
Driver Hours
Agency Days
Drivers /
Agencies
Instructions
Driver
Availability
YORKIES
Booking Request
Booking Confirmation
Payment
Invoice
Bookings
Invoicing
Drivers
Vehicles
Internet User
Vehicle out of service
New Vehicle
Documents
Fleet Maintenance
PRINCE Introduction 16
Out of scope
• Useful to be clear about the boundary of the system / project
• Define what is out of scope
– May change
– May still need to be studied
• e.g. for Yorkies the following are out of scope:
– Driver and staff payroll and HR
– Vehicle maintenance, asset management and insurance
– Marketing
PRINCE Introduction 17
Business Case
• To document the justification for the undertaking of the project, based
on the estimated cost of development and implementation against the
risks and anticipated business benefits and savings to be gained.”
• A justification for an investment
– based on costs versus anticipated business benefits
• Means of assessing alternative and competing investments
• Means for continuing to assess viability of project
– Business Case will change during the project
– In Prince 2 reviewed by the Project Board at
Initiation, end of each stage, when exceptions arise, closure
• Used to assess whether benefits achieved when project delivered
– Post implementation review
PRINCE Introduction 18
Business Case -- Prince 2 Definition
“To document the justification for the undertaking of the project, based on the
estimated cost of development and implementation against the risks and
anticipated business benefits and savings to be gained.”
• Contents:
– Executive summary
– Reasons
Why the project is needed – including some analysis of the current situation
– Options
Outline rejected solutions and detail the preferred option
– Costs and Benefits expected
Explanations and assumptions
– Investment appraisal – cost benefit analysis
Financial justification
– Risks
May be too great?
– Timescales – outline plan
• The primary mechanism of project decision-making
PRINCE Introduction 19
The Business Case in the Project Lifecycle
Feasibility study
----------------------------------
Initial Business Case
before major resources
committed
Requirements analysis
and specification
---------------------------------
Business Case
confirmed after
detailed requirements
Solution design
------------------------------------------ Decision Point / End Stage
Business Case
confirmed once
development cost estimated
Solution development
and implementation
---------------------------------
Benefits realization
checked
Operation of new
processes and systems
Business Case
revisited before
deployment
PRINCE Introduction 20
Costs and Benefits
• Compare expected cost of development and operation with the
benefits of having the system in operation
• Do estimated income and other benefits exceed estimated costs?
• Try to estimate everything in financial terms
– Need to ensure that the project is a better investment than the bank
– Known as Cost Benefit Analysis (CBA) or Return On Investment (ROI)
• In theory, most objective way to compare merits of options
• Many organisations require full Cost Benefit Analysis before
committing to any project
PRINCE Introduction 21
The Project Profit & Loss Statement
• Usually developed for a 5 year timeframe
• Includes incremental revenue
• Project related costs
– Development and implementation
– On-going support and maintenance
• Project related expense savings and other benefits
• Net return from project
PRINCE Introduction 22
Costs
• Development costs
– Salaries of all staff involved in the development
Developers and users
– External supplier costs
– Software costs
• Setup costs
– Hardware and ancillary equipment
– Data Conversion
– Staff training and retraining
– Recruitment
– Relocation
– Disruption and loss of productivity
• Operating costs
– Staff
– Consumerables
– Support
– Maintenance
PRINCE Introduction 23
Benefits
• Direct benefits
– Reduction in staff costs
through job losses, overtime reduction, increased workload, reduced
accommodation costs
– Increased sales
– Fewer product returns / complaints
– Reduced maintenance costs
– Increased production capacity / faster throughput
• Compliance benefits
• Can estimate financial values
– But very dependent on assumptions
PRINCE Introduction 24
Intangible benefits
• How can you quantify?
– improved product quality
– improved service to customers
– improved customer loyalty
– better brand awareness
– greater job satisfaction for employees
– improved management information
• If you can’t measure it, you can’t improve it
PRINCE Introduction 25
Project Organisation
• Principles
• Structure
• Customer/Supplier relationship
• Project Board
– individual roles
• Project Managers and Team Managers
• Project Assurance
• Programme Organisation
PRINCE Introduction 26
Project Management Team Structure
Corporate or programme management
Within the project
management team
From the customer
Senior User(s)
Executive
Senior Supplier(s)
From the supplier
Lines of authority
Lines of assurance
responsibility
Lines of
supplier/advice
Business, User And
Supplier Project
Assurance
Change
Authority
Project Manager
Project Support
Team Manager(s)
Team members
PRINCE Introduction 27
Project Management Organisation Structure
• Defines roles
– may be split, shared, or combined
depending on project need and size
• Responsibilities assigned to job descriptions
• Temporary organisation
– but runs throughout project
– clarify relationship between project and normal authority
PRINCE Introduction 28
Customers and Suppliers in PRINCE
• Customers
– commission the work and
benefit from the end results
– usually pay for the work
– users will operate the final
product
– users and customers may be
the same group
• Suppliers
– provide specialist resources,
skills, and services
– may be several subcontractors
to a major supplier
PRINCE Introduction 29
Project Board
• Have total authority (within the Project Mandate) for the project
– make all major decisions
– approve all major plans and authorise any major deviations
– responsible for commitment of resources
– sign off each stage and authorise next stage
• Responsible for ensuring that project delivers to the Business Case
– often delegate the Project Assurance Role
• Manage by exception
• Ideally board members stay throughout the project
• Consists of Executive, Senior User, and Senior Supplier
exec
PRINCE Introduction 30
Key Interest Groups
• Business
– the organisation as a whole that is to benefit from the project
– represented on the Project Board by the Executive
– the Customer for the project
• User
– individual, group, or groups who will use and benefit from the final
product
– represented on Project Board by Senior User
– ensures equality and performance of the final product
• Supplier
– creator of the end product
– represented by Senior Supplier on Project Board
– may use in-house and/or external teams in a complex structure
PRINCE Introduction 31
Project Manager
• Manages the project on day-to-day basis
– within constraints set by Project Board
• Ensures that project delivers on time, to cost, and at
required scope and quality
PM
• PRINCE assumes that PM from Customer and teams from
Supplier
– if Supplier PM then Supplier/Customer interface is Project Board
to Project Manager
• Manage the work, not do it
– should avoid detail and keep holistic view
PRINCE Introduction 32
Team Manager
• Optional role
• Focuses on production of particular products and specialist
areas
• Team Manager role is determined at Project Initiation
• Often required in
– large projects
– highly technical projects
– geographically spread projects
• PM and TM may be the Customer/Supplier split
PRINCE Introduction 33
Project Assurance
• Provide the Project Board with an independent view of the project
– ensure meets Business Case on time, to budget, and at required quality
• Responsibility of Project Board but
– busy people
– may be delegated
but for some aspects e.g. Business Case may be closely involved
– independent of Project Manager
• Specific responsibilities of Project Board members
– Executive
focuses on the business issues
– Senior User
focuses on the product meeting User’s Requirements
– Senior Supplier
focuses on the specialist/technical integrity of the product
PRINCE Introduction 34
Project Support
• Provide administrative help to the Project Manager
• May be an official body within the organisation supporting
several projects
• Acts as centre of expertise for
– estimating
– planning
– quality assurance
– configuration management
– use of project support tools
PRINCE Introduction 35
Programme Organisation
• Authority lies with the
Programme Director
Programme Executive
• Day-to-day
management
delegated to
Programme Executive
Programme Director
Change Programme Design
Manager Manager Authority
Project
Boards
Programme
Support
Programme Assurance
Project Assurance
Project
Managers
Project
Support
• Complex
communications can
cause confusion
– need careful
clarification in
job definitions
control and reporting
procedures
Team
Managers
PRINCE Introduction 36
Planning
• Why plan?
• What is in a project plan?
• How far should it go?
• How should it be developed?
• How should it be maintained?
PRINCE 2
has all the
answers!?
PRINCE Introduction 37
Why plan?
To know where we’re going!
• Is the target is obtainable?
– How much will the project cost?
– How long it will take?
• Helps manage the project
– Communicate—everybody knows what is going
on
– Basis for delegation
– Ensures that equipment and people are available
when needed
• Measuring and control document
• Highlights potential problems—Risks
PRINCE Introduction 38
Levels of Plan
• Two basic levels
Project Plan
– Project Plan and Stage Plan
• Third level
– Team Plan is optional
• In initial stages produce overall Project Plan
Stage Plan
• Stage Plan for each stage
• The lower the level
– shorter time frame, more detail
• Flexible planning—project decides number of stages
and number of levels
Team Plan
– small projects may only have two stages:
Initiation and “Doing”
PRINCE Introduction 39
Project Plan
• Provides an overview of the whole project
• Used to monitor costs and progress by Project Board
• Identifies deliverables, resources, and total costs
10
• Defines stages
Code & Test A
40
13/11/95
– provide control points
• Later versions of Project Plan
– produced at the end of each stage
– reflect progress and changes made
4/12/95
Integration
Test
6 Duration
0
Begin
Coding
16/10/95
0
5/12/95
Code & Test B
13/11/95
Earliest
Start
16/10/95
4/12/95
Latest
Finish
29/1/96
6
29/1/96
Hand Over for
Acceptance
Testing
29/1/96
Code &
Test E
20
Check Spec
27/11/95
16/10/95
4/12/95
10/11/95
10
Code & Test C
13/11/95
24/11/95
5
• Tolerances defined for Project Plan
Check module E
spec
13/11/95
24/11/95
– if exceeded must go to Project Board with suggested Exception Plan
• Part of the Project Initiation Document (PID)
PRINCE Introduction 40
What is in the Project Plan?
• Plan Description—brief description of what it covers
• Project prerequisites
– what must be there at the start and what must remain there for success
• External dependencies and any assumptions
• Project Plan covering (at project level)
– Product Breakdown Structure
– Product Flow Diagrams
– Product Descriptions
– Gantt chart with identified stages
– Activity network
– Financial budget
– Resource requirements
The Project Plan
PRINCE Introduction 41
Product-based Planning
• Key to PRINCE
• Recommended technique for all planning
Products
Management
Specialist
Quality
Project
Mandate
Planning
Permission
Product
Breakdown
Structure
Product
Descriptions
Product
Descriptions
Plans
Structure
Infrastructure
Interior
Completed
House
Product
Flow
Diagram
PRINCE Introduction 42
Basic Product Breakdown Structure
Products
Management
Specialist
Quality
• PRINCE suggests this structure
– ensures management and quality products are not forgotten
• PRINCE provides standard set of management and quality products
– tailor to organisational, industry, and project circumstances
PRINCE Introduction 43
Management Product Breakdown Structure
Management Products
Products of
Start-up
Project Mandate
Project Brief
Project Organisation
Initiation Stage Plan
Project Board Approval
Method of Approach
Products of
Initiating a Project
Products of
Controlling a
Stage
PID
next Stage Plan
Filing Structure
Project Board Approval
Work Package Authorisations
Checkpoints
Highlight Reports
Exception Reports
Project End Notification
Products of
Completing &
Starting Stages
next Stage Plan
updated Business Case
updated Project Plan
Updated Risk Log
End Stage Report
Project Board Approval
Products of
Project Closure
Lessons Learned Report
Project Closure Recommendation
Follow-on Action Recommendations
Post Implementation Plan
End Project Report
PRINCE Introduction 44
Developing
Product Breakdown Structures
• Specialist products can breakdown in several ways
• May have big influence on success, quality of end products, communications
• Development of PBS should be iterative
– may require specialist skills
e.g. architects, software engineers, civil engineers, etc.
• Re-use PBSs developed from other projects
• PBS need not be a diagram
– could manipulate levels using Outliner in word processors
Products
Management
Specialist
Quality
PRINCE Introduction 45
Mansion (specialist)
Product Breakdown Structure
•Small island in Thames
•Electricity, gas, and water already laid on to existing
building which will be demolished
–land has planning permission for a large house
–budget is set at £1 million
•Specialist products can breakdown in several ways
–by specialist skills
–by nature of product
–by industry or organisational standards
Plans
Architect's Plan
Contractors Appointed
Site Cleared
Materials Purchased
New House
Structure
Foundations
Walls
Roof
Doors & Windows
Infrastructure
Wired
Central Heating
Plumbed
Communications
Interior
Plastered
Tiled
Painted
Carpets & Curtains
Fittings
PRINCE Introduction 46
Product Descriptions
• Provide a guide against the finished product
– used in quality control
• State what is required of the product
Product
Descriptions
– planner can calculate effort required
– allocate to individuals or teams
• Methods and standard practices often provide outline
Product Descriptions
– known as Product Outlines
– management and quality Product Outlines provided by PRINCE
manual
– systems development projects could use SSADM Product
Descriptions
– Project Support Office, User, or Customer may have standards
– can be re-used or customised
PRINCE Introduction 47
Product Descriptions contain:
• Title
• Clear statement of purpose of the product
• Clear statement of the content of the product
• Product(s) from which it is derived
• Standards that product must conform to
Product
Descriptions
• Who is responsible for producing it
• Quality criteria to be applied
• Quality control method to be used
people or skills required for review/test and approval
PRINCE Introduction 48
Sample Product Description:
Cleared Site
Product Title: Cleared Site
Purpose: to enable foundations to be laid and building to commence; to enable vehicles
and equipment to have easy access to the site
Composition: cleared area on which building is to be done and 10 metres clearance all
round. No damage to any trees outside the area. Access cleared 4 metres wide from
entrance to site through to building area.
Derivation: from site plan in architects plans
Format and presentation: photographs should also be supplied before and after to aid
quality checking, otherwise product will be presented by a site visit.
Allocated to: demolition contractors and site clearance contractors.
Quality criteria: Has all rubble been removed from site? Are water, gas, electricity, and
telephone lines intact? Is access manageable by 3 ton truck? Is all vegetation cleared
within 10 metre area?
Type of quality check: site visit and inspection of photographs including aerial
photograph.
Skills required for review and approval: review will be conducted by architect, owner,
and building manager. If necessary representatives of gas, electricity, and telephone
companies may be required to verify that connections are still in place.
PRINCE Introduction
49
House Product Flow Diagram
• Diagram read from left to right
and/or top to bottom
– indicating dependency and
therefore time
– derivations on Product
Descriptions can help identify
dependencies
• May have several Product Flow
Diagrams
– one for each level of plan
– at high level dependencies may be
crude but resolve at stage level
• Can be used by Project Board to
check progress
PRINCE Introduction 50
How to develop
Product Flow Diagrams
• Responsibility of Project Manager
– but involve all product developers
• Determine which products depend on which
others, which products can be developed in
parallel
• Determine any dependencies on external products
• May be best to start with specialist products
– add in management and quality later
• Iterative approach
• May be useful to work as a team with a white
board
– Post-it notes useful
• One approach:
– identify all initial and final products
– trace back from final to initial
Project
Mandate
Planning
Permission
Plans
Structure
Infrastructure
Interior
Completed
House
PRINCE Introduction 51
Activity network
• Each Activity has duration, start
& finish times, etc
10
• Time moves from left to right
– one start and one end node
• Tools e.g. PMW, Microsoft
Project, etc
Code & Test A
40
13/11/95
4/12/95
Integration
Test
6 Duration
0
Begin
Coding
16/10/95
0
5/12/95
Code & Test B
13/11/95
Earliest
Start
16/10/95
4/12/95
Latest
Finish
29/1/96
6
29/1/96
Hand Over for
Acceptance
Testing
29/1/96
Code &
Test E
20
– invaluable in large projects
– show actuals against plans
– include resources, costs,
subprojects, levelling, calendars, ....
– multiple representations
Activity Networks, PERT, Gannt,
Resource Charts, Work Plans, etc
16/10/95
Check Spec
27/11/95
4/12/95
10/11/95
10
Code & Test C
13/11/95
24/11/95
5
Check module E
spec
13/11/95
24/11/95
PRINCE Introduction 52
Gantt Chart - many styles
PRINCE Introduction 53
Stages
“Collection of activities and products whose delivery is
managed as a unit by the Project Manager”
• Partitions of project force Project Board to assess
viability against Business Case
• Provide review and decision points
– key decisions made before detailed work begins
– clarifies impact of any external influences
– provide planning horizons
cannot plan the whole project in detail
Stage Plan below Project Plan level
enables scalability—no set number of stages
Initiation
Stage
Stage 1
Stage 2
Stage 3
PRINCE Introduction 54
Planning Process
• Planning is a repeatable
process
– uses product-based
approach
– form and content
Company Planning Standards
Planning
Quality
Quality
IP1 Plan
Planning a
Project
IP2
Planning
Project
Approach
Designing a
Plan
PL1
Plan
Design
PL
Product
Flow
Diagrams
Defining and
Analysing
Products PL2
Identifying
Activities and
Dependencies
PL3
Product
Descriptions
Project
Plan
Estimating
PL4
• Determines the sequence Authorising a
Work Package
of production
Estimated
Activities
CS1
• Estimates and schedules
activities needed for
creation and delivery of
products
Planning a
Stage
SB1
Producing an
Exception Plan
SB6
List of
Activities
Stage
Plan
Completing a
Plan
PL7
Product
Exception
Checklist
Plan
Assessed
Plan
Completed Plan
for approval
Authorising a
Project or Plan
DP2 or DP3
Analysing Schedule
Risks
PL6
Risk Log
Reviewing
Stage Status
CS5
Activity Dependencies
• Establishes and defines
products needed
Defining
Project
Approach
SU5
Scheduling
PL5
Resource
availability
Giving ad hoc
Direction
DP4
PRINCE Introduction 55
Planning Summary
• Need for a plan
• Planning horizons
– Project, Stage and Team Plans
• Product-based planning
• Product Breakdown Structures
• Product Descriptions
• Product Flow Diagrams
• Scheduling
• Stages and Exception Plans
• The Planning Process
PRINCE Introduction 56
Project Control
• Ensures project on schedule, to cost, to scope, and to quality
• Feedback
Specification
• Control levels
• Tolerance
• Control through the project life cycle
– Start Up
– Initiation
– Progression
– Delegation
– Exceptions
– Closure
Completion
Start
Cost
Time
PRINCE Introduction 57
Project Control Feedback
• Central role of project management
• Enables informed decisions to be made
• Ensures project on schedule, to cost, to scope, and to quality
• Operates at each level of project management
• Feedback loop
Monitor
PRINCE Introduction 58
Levels of Control
external
information
Project Initiation Document:
Project Plan
Risk Log
Business Case
Authorisations
Direction
Closure
Requests
for Change
Product
Sign-offs
Project
Issues
Project
Board
End
Stage
Reports
Exception
(Assessments)
Reports
End Project Report
Follow-on Action Recommendations
Lessons Learned Report
Requests Highlight
for advice Reports
Project
Manager
Work Packages
Work
Package
status
+ completions
Project
Issues
Team
Plans
Checkpoint
Reports
Risk Log
Team Manager
/Teams
PRINCE Introduction 59
Tolerance
• Tolerance is the permissible
deviation from plan without
attention of Project Board (or
higher)
– within tolerance Project Manager
has freedom of decision
• Set in Project Mandate and
developed in Project Brief
upper £
tolerance
£
• Agreed for each stage and for
overall project
• Tolerance can be set on cost, time,
scope, and quality
– specific values set for time and cost
actual
planned
upper time
tolerance
Time
PRINCE Introduction 60
Controlled Start Up
user
En
Starting up a Project
PM
Project Brief and Approach
PM Team structure & job definitions
Initiation Stage Plan
exec
Authorisation to proceed
PRINCE Introduction 61
Controlled Initiation
user
En
Project Initiation Document:
PM
Background, Definition,
Assumptions, Business Case,
Organisation , Project Plan,
Controls, Quality Plan,
Communication Plan, Exception
process, Risk Log, Contingency
Plans, Filing Structure
exec
Approval of PID
PRINCE Introduction 62
Business Case
• Project Board monitors ongoing viability of project against the
Business Case
• Justifies the project based on costs versus anticipated business
benefits
• Contains
– reasons
– investment appraisal
costs and benefits
– time scales
• Reviewed by the Project Board at
– initiation
– end of each stage
– when exceptions arise
– closure
PRINCE Introduction 63
Controlled Progression
user
PM
Stage Plans (Exception Plans)
En
(Project
Plan, Business Case, Risk Log)
End Stage Reports
exec
Highlight Reports
Authorisations
Approved Plans and Reports
PRINCE Introduction 64
Highlight Report
• Provides Project Board with regular information about stages
– at defined intervals
– used in managing by exception
• Contains
– date and period covered
– budget and schedule status
– products completed in current period and to be completed in next
period
– potential /actual problems
– Project Issue status
– impacts of any budget and schedule changes
PRINCE Introduction 65
Controlled Delegation
Completed Work Packages
Product Sign-offs
Quality Log
Checkpoint Reports
Team Plans
Stage Plan
PM
Work Packages
Stage Plan
PRINCE Introduction 66
Checkpoint controls
• Part of Executing a Work Package (MP2)
• Operates at team level
– involving Project Manager and Team Managers
– could be formal or informal meeting + formal written report
– reports the status of work for each team member
• Occurs at frequency defined in Stage Plan
• Checkpoint Report includes
– period covered
– follow-up from any previous reports
– activities, products delivered and quality work performed
– problems or deviations from plan (actual or expected)
– activities and products planned for the next period
• Checkpoint Report basis for Highlight Report
PRINCE Introduction 67
Ongoing control mechanisms
• Work Packages
– release work to individuals or teams
– agreed work packages containing
Product Descriptions
time /cost constraints
– useful for controlling contractors or sub-contractors
• Quality control and Quality Log
– varies depending upon type of project
can use Quality Review or more objective testing procedures
• Risk Log
– describes risks and counter measures and status
– updated through project
PRINCE Introduction 68
Project Issues
• Raised by anyone
– any deviation from specification
– Project Issues carefully controlled throughout the
project
PM
• Request for Change
– undergoes change control procedures
• Off-Specification
– record of current or forecast failure to meet a
requirement
– associated with time, cost, or quality
i.e. a management issue
Issue Log:
Off-Specifications
Requests for Change
Statements of Concern
Questions
• Undergo exception procedures
– if needed
PRINCE Introduction 69
Controlling Exceptions
user
Exception Reports
proposed Exception Plans:
(Project Plan, Business Case, Risk Log)
PM
Requests for advice
exec
Project Board direction
Authorised Exception Plan (replaces Stage Plan)
Premature Close
PRINCE Introduction 70
Controlled Closure
user
PM
Project Closure Notification
Customer acceptance
En
Operational & maintenance acceptance
Follow-on Action recommendations
Post Project Review Plan
End Project Report
Lessons Learned Report
exec
Confirmed acceptance
PRINCE Introduction 71
Project Control Summary
• Control levels
• Tolerance
• Control through the project life cycle
– Start Up
– Initiation
– Progression
– Delegation
– Exceptions
– Closure
Monitor
PRINCE Introduction 72
Management of Risk
• Definition of risk
• Risk types
• Risk Analysis
• Risk Log
• Risk Management
• Ways of handling risks
• Risk responsibilities
• Risk in the Process Model
• Risks and Programmes
PRINCE Introduction 73
Risks
• Definition of risk
“The chance of exposure to the adverse consequences
of future events”
• Projects are unique
– more susceptible to risk than routine work
• Some risks are standard and apply to all types of project
– others are project specific
• Essential part of Project Management
PRINCE Introduction 74
Types of risk
• Business risk
– Products of project do not achieve expected benefits
– Business risks managed by Project Board
• Project risk
– not achieving results within cost and time
– managed on day-to-day basis by Project Manager or Team Manager
– may need reference to Project Board
• All risks documented and managed in the Risk Log
PRINCE Introduction 75
Typical business risks
• How valid and viable is the Business Case?
– does the project still support the corporate business strategy?
e.g. strategic direction, commercial issues, market change
– how stable are the business areas involved?
• External factors
– political factors and public opinion
– any possible legal changes
– environmental issues
• Organisational factors outside the project
– impact on the customer of the results of the project
– impact of failure or limited success on the whole organisation
– risk of the result meets requirements but not expectations
• How does the Programme impact on the Project?
PRINCE Introduction 76
Typical project risks
• Depends heavily on project
• Contractual issues
– dependent on a contractor (or other third party)
– failure of the contractor to deliver satisfactorily
– disputes
• Organisational factors
– conflict or staff responsibilities in project work
– lack of project culture within the Customer organisation
– skill shortages, personnel problems and training issues
– culture clashes between Customer and Supplier
• Specialist issues
– how well are the requirements specified?
– how well can the requirements be met?
– risk of using new technology and techniques
– problems of quality control and testing
PRINCE Introduction 77
Risk Analysis and Risk Management
Planning
Resourcing
Identification
Estimation
Evaluation
Controlling
Monitoring
Risk Analysis
Risk Management
PRINCE Introduction 78
Risk analysis
• Highly iterative
• Risk identification
– determines potential risks
• Risk estimation
– decides how important each risk is
– assesses likelihood and severity
– could quantify by giving each a weighting
– risk value = likelihood x severity
• Risk evaluation
– decides whether level of risk is acceptable
– if not, what actions can make it more acceptable
• If risk cannot be accepted may need to review justification for
project
PRINCE Introduction 79
Initial Risk Analysis
1
high
0
SEVERITY of
IMPACT
medium
Severity of Impact 0 = no increase in timescale
or cost
10 = significant increase in
cost(>100%) and/or
significant increase in
timescale (100% over-run)
low
0
Likelihood
low
0 = probability of occurrence < 5%
5 = probability of occurrence approx. 50%
10 = probability of occurrence >95%
medium
LIKELIHOOD
high 10
PRINCE Introduction 80
Risk Log
• Identifies and classifies risks
• Summarises and describes risks and their status
more detailed descriptions of risks can also be held
• Contains
– name, id, type, author, date identified, date last changed
– description
– ownership
– likelihood
– severity
– description of any counter measures
– status
• Created during Start-up
– reviewed at Project Initiation
– reviewed at every End Stage Assessment or Exception
PRINCE Introduction 81
Ways of handling risks
• Prevention
– counter measures stop the threat or prevent it having any impact
• Reduction
– reduce the likelihood of risk occurring
– limit the impact to acceptable levels
• Transference
– risk impact transferred to third party
e.g. insurance policy or penalty clause
• Contingency
– actions are planned if the risk occurs
• Acceptance
– Project Board accepts that the risk may occur
counter measures are too expensive or risk is highly improbable
• Risks could have actions in all above categories
PRINCE Introduction 82
Risk management
• Separate from and follows risk analysis
– though often overlap
• Planning counter measures
– Identify quantity and type of resources
– Detailed plan for inclusion in Stage Plan
– Gain management approval
• Resourcing the plans for risk counter measures
– add to Stage Plans and budgets
• Monitoring
– whether risks are developing
– predicting risks on an ongoing basis
– checking that overall risk management is effective and that planned
actions are having the desired effect on the risks identified
• Controlling—ensuring that the plan is carried out
PRINCE Introduction 83
Risk responsibilities—Project Manager
• Day-to-day management of risks
• Ensure risks are identified, recorded, and regularly reviewed
– responsible for Risk Log
• Modify plans to include actions to avoid or reduce risks
• Suggest “risk owners”
– who keep an eye on the risk
– might be Project Board members
particularly for external risks
PM
PRINCE Introduction 84
Risk responsibilities—Project Board
• Notify Project Manager of any external risks
– programme risks or external business risks
• Decide on Project Manager’s recommended reaction to risks
• Balance risks and benefits of project
• Decide on Project Manager’s recommendation on “risk owners”
– could be risk owners for external risks
user
exec
PRINCE Introduction 85
Management of risk
in the PRINCE process model
• Throughout project but particularly in:
• Risk analysis:
– Preparing a Project Brief (SU4)
– Planning a Project (IP2)
– Refining the Business Case (IP3)
• Risk management:
– Analysing Risks (PL6)
– Executing a Work Package (MP2)
– Updating the Risk Log (SB4)
– Closing a Project (CP)
ensure follow-up for continuing risks on end-products of project
PRINCE Introduction 86
Project risks and Programmes
• Many risks will be common
– should be centralised at programme level
ensures consistent approach
• Design Authority
– monitors risks associated with the programme’s products and
outcome
• Programme Manager
– focuses on programme wide risks and project inter-dependent risks
• Change Manager
– ensures approach to risks appropriate
PRINCE Introduction 87
Management of Risk
Summary
• Definition of risk
• Risk types
Planning
• Risk Analysis
• Risk Log
• Risk Management
• Ways of handling risks
Resourcing
Identification
Estimation
Evaluation
Controlling
• Risk responsibilities
• Risk in the Process Model
• Risks and Programmes
Monitoring
Risk Analysis
Risk Management
PRINCE Introduction 88
Quality in Projects
• Quality quotes and definitions
• Quality in projects
• Quality criteria
• Quality reviews
– planning and preparation
– review
– follow-up
– roles and responsibilities
– some tips
PRINCE Introduction 89
Quality quotes
• Quality:
“The totality of characteristics of an entity which bear on its ability to
satisfy stated and implied needs.”
From ISO 8402
• Quality Assurance and Control:
“The quality system should be an integrated process throughout the
entire life cycle, thus ensuring that quality is being built-in as a
development progresses, rather than being discovered at the end of the
process.”
“Problem prevention should be emphasised
– From BSI “Guidelines for the application of BS5750”
PRINCE Introduction 90
Quality Management
• Ensures that the quality expected by the customer is achieved
• Quality System
– has organisation structure and procedures to implement quality
management
– Customer and Supply may have quality systems
– PRINCE can be part of a corporate quality system
PRINCE helps organisations meet ISO 9001
• Quality Assurance
– sets up the Quality System and ensures it works
– maintains, audits, and evaluates Quality System
– often separate and independent from projects
otherwise Project Assurance within project takes Quality Assurance role
PRINCE Introduction 91
Quality Planning and Control
• Quality Planning establishes objectives and requirements for
quality
– identify customer’s quality expectations before project begins
– approach for project defined in Project Quality Plan (part of PID)
also contains Configuration Management Plan
and approach to change control
– Stage Plans identify quality activities and resources—Stage Quality
Plans
– Product Descriptions identify quality criteria
• Quality control
– ensures that the products meet the quality criteria
– examines products to determine that they meet requirements
– can use various techniques of assessment
PRINCE Introduction 92
Quality in projects
• In production, quality management
will be part of a defined process
• Because projects are unique each
requires its own quality system
Project
Approach
Customer’s
Quality
Expectations
Project
Quality
Plan
– although benefits from “best practice”
Project
Boundary
Stage
Quality
Plan
Product
Descriptions
including
Quality Criteria
Project
Issues
ISO
9000
Quality
Policy
Quality
Management
System
Quality
Assurance
Quality
Control
(Reviews)
Quality
Log
PRINCE Introduction 93
Quality criteria
• Objective criteria
– measurable
– “yes” or “no” answer
• Quality checking for objective criteria
– testing, measurement, checklists
• Subjective criteria
– involve judgement or opinion e.g. market acceptability, ease of use, testing
– can try to define objective criteria even for apparently subjective factors
• Checking conformance to subjective criteria
– quality review techniques
– formal quality reviews or informal walkthroughs
PRINCE Introduction 94
Quality Review
• Provides an approach to examining products against subjective
criteria
• Identifies errors in defined products
• Partnership involving all those with interest in, or specialist
knowledge of, the product
• Could be plans, reports, models, prototypes
PRINCE Introduction 95
Objectives of Quality Review
• Ensure product meets business, user, and specialist
requirements
– early identification of defects
– assess conformity of a product against set criteria
• Provide a platform for product improvement
• Involve all those with an interest in the product
– spread ownership of the product
– gain commitment from all involved
• Provide a mechanism for management control
– provide milestones
– monitor standards
PRINCE Introduction 96
Quality Review planning
• Stage Quality Plan must define:
• Which products to Quality Review
– Quality criteria defined in Product Description
– How the product will be tested
• When the product will be tested
– Plan the timescale for each Quality Review
• Who will test the product
– Identify reviewers and add them to resource plans
• All part of Project Plans and Stage Plans
• Also documented through Quality Log
PRINCE Introduction 97
Preparation for the Quality Review
• Confirm availability of reviewers
• Agree dates for
– submission of material, return of comments, and review
Preparation
• Distribute product and Product Descriptions if possible
– or make available for inspection
• Assessment of product against quality criteria
– Production of Error List showing major errors
– Annotation of minor errors on the product
– Return of annotated product and error list to Producer
• Agree agenda
Review
Meeting
Follow up
PRINCE Introduction 98
Review meeting
• Discussion and clarification of each major error
identified
• Agreement and documentation of follow-up action to
each error
Preparation
• Summary of actions at the end of the meeting
• Agreement on Quality Review outcome
Review
Meeting
Follow up
PRINCE Introduction 99
Follow up
• Notification of Quality Review results
• Plan for any remedial work required
• Sign-off of the product
Preparation
– following successful remedial work
Review
Meeting
Follow up
PRINCE Introduction 100
Quality Review results
• Chairman obtains consensus on result of review
• If reviewers cannot sign-off product or disagree
– becomes Project Issue
• Possible results:
– Error-free product can be approved immediately
– Product signed-off after correction of errors
– Product needs further review as correction requires major changes
• Review may also be postponed if:
– insufficient or inexpert Reviewers
– Reviewers not studied product
– product not ready for review
PRINCE Introduction 101
Roles in the Quality Review
• Roles specific to Quality Reviews
– Review chairman
– Producer
– Reviewers
– Scribe
• Also involved
– Project Manager
– Team Manager
often roles of PM and TM combined
– Project support
PRINCE Introduction 102
How to make quality reviewing work
• Error/opportunity identification not correction
• Address the Producer/Reviewer psychology
– identify defects in the product not in the producer
– our product rather than your product
• Management and peer pressure
– managers do not attend—in their role as people managers
• Checklists for standard criteria help
– reviewers need guidance on what acceptable quality is
• Chairman should not act as Reviewer
• If Reviewers cannot attend
– Chairman can accept error lists or replace Reviewer
• May require cross-project representation at Quality Reviews of
inter-project products
PRINCE Introduction 103
Summary
• Quality is important at all stages of a project
– must be built into project plans
Project Quality Plan and Stage Quality Plans
– criteria defined in Product Descriptions
• Quality Reviews are the primary mechanism of quality control
– for subjective products
– defined procedures for performing quality reviews
planning, preparation, review, and follow-up
– defined roles
PRINCE Introduction 104
Change Control and Exceptions
• Change control
– considers changes to scope and specification
– will relate to products of project
– usually based on something outside the project changing
– Requests for Change
• Exceptions
– changes to status of project
e.g. falling behind, going over budget
– affects management or quality products
– Off-Specifications
• Both dealt with by Project Issues
• Organisation may have own change control standards
– PRINCE provides guidelines for those without
PRINCE Introduction 105
Project Issue Log
• Summarises and identifies Project Issues and their status
• Managed by Project Manager
PM
• Contains
– identifier
– type
– author
– date identified, date last updated
– description
– status
Issue Log:
Off-Specifications
Requests for Change
Statements of Concern
Questions
PRINCE Introduction 106
Change Control Authority
• Who can authorise changes?
• Ultimate responsibility is the Project Board
– but if many changes
do they have time?
consider Project Board approval only for high priority changes with
delegation of others
how will changes be funded?
• Change authority group may have delegated responsibility and
budget for changes
– useful if large number of changes forecast
otherwise will require considerable exception handling by Project Board
• Authority for change control must be decided in initiation and
written into job definitions
PRINCE Introduction 107
Considering Changes
• Consider benefits of making the change and impact on
Business Case
• Balance
– advantages of implementing the change
– potential savings
Against
– costs and delays incurred by implementation
• Consider whether change should wait until after project ends
• Consider impacts on programme and on other projects
• If product approved by Project Board then can only be changed
with their approval
• Check Product Description for necessary changes
PRINCE Introduction 108
Change Control Approach
• Basic approach
– change identified and logged as Project Issue in Issue Log
– evaluated to see whether further investigation required
– if so, impact analysis performed
– Project Manager may then decide whether to implement change or whether
needs referral
results of impact analysis evaluated by Senior User (or representative)
– Project Issue may be
accepted for implementation
made pending
rejected
– Issue Log updated with results
– if implemented Exception Report produced which will normally produce
Exception Plan for acceptance by Project Board into the next Stage Plan
PRINCE Introduction 109
Prioritising Changes
• Project Issues are prioritised by their author
• Priority may be changed after review
• Possible priority ratings are:1. mandatory—final product won’t work without the change
2. important—absence would be inconvenient but could be worked around
3. nice to have—not vital
4. cosmetic—of little importance
5. no change required
• Project Issue returned to the author acknowledging receipt and future
consideration
PRINCE Introduction 110
Impact Analysis on Project Issues
• What needs to change?
• What effort is required?
• What is the impact on the Business Case?
• What is the impact on the risks?
• Consider impacts on business, user, and supplier
• Consider effects on other projects or on programme
– may require programme representative in Projects Change Authority
– or screen changes at programme level
• Re-evaluate priority after impact analysis
PRINCE Introduction 111
Off-Specifications
• Where expected failure to meet
a management requirement
– cost, time, and/or quality
• Consider changes required to
plan
• Decide whether within project
tolerance
– if not possible within tolerance
Project Issue
becomes an exception and is
handled through exception
procedures
– if Project Board accepts without
corrective action it becomes a
“Concession”
upper £
tolerance
£
actual
planned
upper time
tolerance
Time
PRINCE Introduction 112
Controlling Exceptions
user
Exception Reports
proposed Exception Plans:
(Project Plan, Business Case, Risk Log)
PM
Requests for advice
exec
Project Board direction
Authorised Exception Plan (replaces Stage Plan)
Premature Close
PRINCE Introduction 113
Summary
• Project Issues
• Change Control Authority
• Change Control approach
– Priorities
– Impact Analysis
• Handling Exceptions
• Project Issues in the process model
PRINCE Introduction 114
Project organisation benefits
• Defines project roles in a clear but flexible way
• Has a clear defined structure for delegation and authority
• Clearly defined formal and informal organisation channels
– between team members, project management, and the business
PRINCE Introduction 115
Project Planning benefits
• Well controlled start, middle, and end of projects
• Divides the project into manageable and controllable stages
• Ensures terms of reference defined at start of the project
• Enables the definition of decision points at appropriate times
PRINCE Introduction 116
Project control benefits
• Enables regular resource commitment from management at
various points
• Management by exception approach through
– regular but short management reports
– senior management meetings only at vital points
• Ensures participation of all users and customers in decision
making
• Provides quality control
• Regularly reviews progress against Business Case and against
plans
PRINCE Introduction 117
Organisation wide benefits
• A standard approach for all projects based on best practice
• Standard terminology and roles
• Good infrastructure and competitive market of trainers,
consultants, and tools
• Accreditation schemes for trainers and consultants
• Good basis for contractual negotiations between customers and
suppliers
• Conformant with ISO 9001 standards
• Active user group—the PUG
PRINCE Introduction 118