---
tags:
  - prince2
  - company
  - management
relates-to: "[[Starting my own game company]]"
note: literature
---
# Definition
[[Project management]] method
Can be used on any project of any size
# Features
- [[Continued business justification]] - the WHY of the business and long term value
- [[Defined organisation structure]] - Ownership of people so they know what is expected of them
- [[Product-based planning]] - product-first, good descriptions and breakdown structure
- [[Stage]] - divide the project into manageable phases
- Tailorable
# Project variables
Six aspects of [[Project performance|project performance]]:
- *Time* - when will the project be finished ?
- *Cost* - what is the cost and the return of investment
- *Quality* - usable software that passes quality checks and is usable
- *Scope* - the scope must be clear for all [[Stakeholder|stakeholders]] through the [[PPD]]
- *Benefits* - benefits must be known, agreed upon and measurable
- *Risk* - risk must be manageable
# Project definition
A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.
- The word organization refers to the project team (people involved in the project)
- The word temporary refers to the fact that each project as a definite start and end date.
- The business case includes: reasons for the project, expected benefits, costs and time
# Core principles
## [[Continued business justification]]
The project must have a business case that shows that the project is value for money, i.e. there must be a reason to start and continue the project with a clear return on investment.
> “Does the project have business justification?” = “Does the project have a valid business case?”

The [[Business case document|business case document]] should feature:
- full business case
- why the project should be done
- costs
- expected benefits
- timescales
It should be checked regularly at least at each [[Stage|stage]] of the project.
## [[Learn from experience]]
A project should learn from the experience of previous projects and it is the responsibility of everyone involved to do so. Projects are unique and therefore always bring something new and valuable for others to learn from. `Learn from experience` should cover the whole length of the project. All lessons should be documented, passed on and made available to other and future projects. 
## [[Defined roles and responsibilities]]
People need to know what is expected from them and what they can expect from others. A team should have a clear available structure that is known and accepted.
A PRINCE2 project has three primary stakeholders:
- Business sponsors - make sure the project delivers value for money
- Users - use the project product and receive the benefits
- Suppliers - provide resources and expertise to produce the product.
These must be represented in the [[Project management team description]] and in the [[Project board]]. This principle answers the questions: 
- What is expected of me ?
- What can I expect from others ?
- Who makes what decisions ?
## [[Manage by stages]]
A PRINCE2 project must be planned, monitored and controlled on a [[Stage|stage-by-stage]] basis and each stage is separated by a [[Project board]] decision. At the end of a stage, the project board decides weather the project should proceed to the next stage or stop.
Increasing the number of stages increases control over the project at the cost of added work for the project board. Advantages of stage are:
- dividing to conquer the project
- having both a very detailed and high level project plan
- [[Learn from experience]] from stage to stage
## [[Manage by exception]]
Manage by exception is to allow a layer of management to have some control over another layer while letting them room to work. The lower layer works as it can and only informs the upper managing layer when a big issue (i.e. an exception) is outside of their ownership. An exception is a big issue that takes a level out of their agreed tolerance.
Therefore, a PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority, as defined by [[Defined roles and responsibilities|the second principle]].
There are 6 tolerances that can be set:
- Time - time it takes for an exception
- Cost - cost it takes for an exception
- Quality - redefining the quality to address the exception
- Scope - redefining the scope to take into account the exception
- Benefits - benefits for the stakeholders in ways to deal with the exception
- Risks - risks to which a value can be assigned to deal with the exception
This is meant to provide the above management layer a system to control the lower management layer.
## [[Focus on products]]
A product must be described in great details so the stakeholders all have the same idea on what the product should be. A detailed description will also help the managers to determine resource requirements, dependencies, scope and activities accurately.
## [[Tailoring]]
The PRINCE2 methodology should adapt to a project requirements to suit its team, size, environment, complexity, importance, capability and risk.
The purpose of tailoring is to:
- Ensure that the project method is project’s environment into account. (i.e., if working in a financial environment, then align it with the existing management structure).
- Ensure with the project board that the project’s controls are based on the project’s scale, complexity, importance, capability, and risk.
# Themes
[[Themes]] are knowledge areas, a part of the project that should be continually addressed. Each theme provides knowledge on a specific area of project management such as business case, planning, quality, risk, etc. They should be tailored to the needs of the project depending on their gravity given the needs:
- Business case: Why? ROI? Benefits?
- Organization: Who? Responsibilities?
- Quality: Level of quality for each product characteristic?
- Plans: How? How much? When? What (Product description)?
- Risk: What if X happens?
- Change: How to deal with changes requests and issues?
- Progress: Where are we now compared to the plan, show progress
## Theme 1 - [[Business case]]
This theme should provide information to help make better decisions regarding the business case to judge weather it's: 
- Desirable: Determine if the output is really required by the users
- Viable: Is it technically possible to deliver this product?
- Achievable: Is it possible to deliver the future benefits?
At every moment during the project, [[Continued business justification]] states that the business case should be valid, which this theme documents and in order to assess as such.
## Theme 2 - [[Organisation]]
This theme aims to help define the project's structure of accountability and responsibilities. A PRINCE2 Project should:
- Have correct business, user, and supplier representation
- Have defined responsibilities for directing, managing, and delivering the project
- Have regular reviews (end of each stage) of the project to check that all is on track
- Have a good communication flow to and from stakeholders
So, each project needs to have direction, management, control, and communication.
[[Stakeholder]]: A stakeholder is any person or group that can be affected by the project or can affect the project. This includes the project team, potential users and other persons external to the project as well as those who may be negatively affected.
## Theme 3 - [[Quality]]
This theme aims to implement that will verify that products are fit for use and meet user requirements. This should ensure that the products meet the user's expectations and can be used as intended.
[[Focus on products|Product focus]] states that products should be clearly defined before development starts. Product descriptions must include the quality criteria information so that all project stakeholders have a common understanding of the products that will be created.
## Theme 4 - [[Plans]]
This theme aims to provide a framework to design, develop and maintain the project plans to facilitate communication and control over the project.
This theme aims to answer the following questions:
- What is required to be delivered?
- How will it be delivered and by whom?
- What is the best approach to creating the products?
- What will the execution steps be?
- How can product-based planning be done?
- What quality has to be reached and how to define this?
- How much will it cost to deliver the products and the project?
- The level of detail required for each plan?
Plans provide the backbone of information used to manage the project and compare progress to.
## Theme 5 - [[Risk]]
This theme aims to provide an approach to identify, assess and control uncertainty during a project to improve the ability of the project to succeed. Risk is defined as a set of events that, should they occur, will have an effect (positive or negative) on achieving the project objectives, i.e. the six aspects of [[Project performance]].
Risk management is about actions you take to enable you to identify, assess and control risk. It is defined in three steps:
- Identification: Identify, capture, and describe the risk
- Assess the risk: Likelihood of the risk and impact on objectives
- Respond: How best to respond to a risk and responsibilities
## Theme 6 - [[Change]]
This theme aims to help identify, assess and control any potential changes to the products that have already been approved, which is inevitable. Issue and change control happen during the full lifecycle of the project. The objective is not to prevent it but to get changes agreed upon before execution.
Each project requires a [[Configuration management]] system that tracks products, records when products are approved and helps ensure the correct versions are being used.
Definitions:
- Issues: event that has happened that was not planned and that requires some management action. Raised anytime by anyone.
- Configuration management is the technical and administrative activity concerned with the creation, maintenance, and controlled change of the configuration of a product.
- Configuration item: name given to an entity managed by the configuration management.
- Baseline: A point of time for a product against which the product is monitored and controlled.
- Release: a complete and consistent set of products that are managed, tested and deployed as a single entity.
## Theme 7 - [[Progress]]
This theme aims to:
- establish how to monitor and compare actual achievements against those planned
- provide a forecast for the project objectives and continued viability
- be able to control any unacceptable deviations
Progress is about comparing current project state to baseline. Project control involves measuring actual progress against the six aspects of [[Project performance]]. Progress can be monitored at three levels:
- Project level (project board)
- Stage level (project manager)
- Work package level (team manager)
Progress control involves measuring actual progress against the performance targets and each project layer wishes to monitor the layer below. Each layer does the following:
- Monitor actual progress against the plan (review plans with forecast)
- Detect problems and identify risks
- Initiate corrective action to fix issues
- Authorize further work to be done
An exception is a situation where it can be forecast that there will be a deviation beyond the agreed tolerance levels. Tolerances are the deviation above and below a plan’s target. For example, the project should take 6 months, with a tolerance of ±1 month. Tolerance levels could also be set for all 6 tolerance areas.
# PRINCE2 processes
A process is a structured set of activities designed to accomplish a specific objective. A process takes one or more inputs, acts on them and delivers defined outputs. There are seven processes that offer activities to help direct, manage and deliver a project.
## Process 1 - [[Starting up a project]]
This process aims to prevent poor projects from starting up. The question "do we have a worthwhile and viable project?" should be asked for each project idea and documented with a [[Project brief]].
Objectives are:
- to ensure business justification for initiating the project (outline [[Business case]])
- to define the [[Project approach]] ("what is the best way of doing this project ?")
- to ask the "why" ("why is the project needed ?")
- to define the deliverables (documented in the [[PPD]])
- to plan the next initiation phase
## Process 2 - [[Initiating a project]]
This process aims to stablish a foundation documented in the [[PPD]] for the organization to understand the deliverables. 
The objectives of this process are:
- the reasons for doing the project
- the scope: what is to be done and what will not be included (project plan)
- how and when the products will be delivered (project plan)
- how the required quality will be achieved?
- how baselines will be established and controlled
- how risks, issues, and changes will be identified and followed up
- how project progress will be monitored and who needs to be informed and how often
- how PRINCE2 will be tailored to suit the project
## Process 3 - [[Directing a project]]
This process aims to enable the accountability of the [[Project board]], give them proper ownership and responsibilities.
The objectives are to provide authority:
- To initiate the project (allow the initiation stage to start which is the first decision)
- To deliver the project’s products (this is done in the delivery stages)
- To close the project which is the last decision by the project board
Other objectives are to:
- Provide direction and control during the project and be interface to the CPC
- Ensure that post-project benefits will be reviewed (see that meetings are planned)
## Process 4 - [[Controlling a stage]]
This process aims to help the project manager to assign the work to be done, monitor it, deal with issues, report progress to the board and take action to keep the stage within tolerance.
The objectives are to:
- Ensure that attention is focused on the delivery of the products
- Keep risks and issues under control
- Keep the business case under review (ask is the project still viable)
- Deliver the products for the stage to the agreed quality within agreed cost and time.
## Process 5 - [[Managing product delivery]]
This process aims to bridge the gap between the project manager and the team manager.s by agreeing on the requirements for acceptance, execution and delivery.
Objectives:
- Products assigned to the team are authorized and agreed on (work packages)
- The team is clear about what has to be produced and understands effort, time, and cost
- Planned products are delivered to the quality expectations and within tolerance
- Accurate progress information is provided by the team manager
## Process 6 - [[Managing a stage boundary]]
This process aims to have the project manager provide the board with a report of the performance of the current stage, update the project plan, business case and create a stage plan for the next stage. The board then reviews this and approves or disapprove the next stage.
Objectives:
- Assure that all products in the current stage are produced and approved
- Review and update the usual documents (business case, project plan)
- Record lessons in the lessons log that can help in later stages or in future projects
- Prepare the stage plan for the next stage and the request authorization to start the next stage
Activities for this process include:
- Plan next stage: Create the next stage plan
- Update the project plan: Confirm what has been done (actuals)
- Update the business case: Update with the latest cost information
- Report stage end: Create the end stage report
- Option: If exception then produce an exception plan (to replace current plan)
## Process 7 - [[Closing a project]]
This process aims to provide a fixed point to check that the project has reached its objectives and that the products have been accepted by the customer.
Objectives:
- Verify user acceptance of the project’s products (delivered by the project)
- Ensure that products can be supported after the project
- Review the performance of the project
- Assess the benefits already realized and plan post project reviews
- Address open issues and risks with a follow-up on action recommendations
The project board close the project and the project manager only prepares the project for closure.
Closing a project activities:
- Prepare planned closure: Confirm the completion and acceptance of the products
- Prepare premature closure: Only if requested by the project board (optional)
- Hand over products: This is described in the change control approach
- Evaluate the project: Compare project objectives and write end project report.
- Recommend project closure: Send a notification to the project board

---

# References
- https://prince2.wiki/extras/what-is-prince2/