PRINCE2

Long established, process driven, Project Management methodology, initially developed by the UK government:

 

  • 1989 -- CCTA developed PRINCE as a UK Government standard for managing IT projects
  • PRINCE = PRojects IN a Controlled Environment
  • 1996 -- PRINCE2 released as a generic project management methodology
  • Derived from earlier methodologies: PROMPT and PRINCE
    • Became regularly applied outside pure IT, around the world
  • 2009 -- Revised as PRINCE2:2009 Refresh
    • Updated to reflect newer business models
    • Simpler
    • Lighter

Introduction

The Importance of Projects

 

Key challenge is to balance two competing imperatives:

  1. Maintaining BAU (Business As usual)
    1. Profitability, Service Quality, Customer Relationships, Brand Loyalty, Productivity, Market Confidence, etc
  2. Transform Business Operations to survive and compete in the future
    1. Looking forward and deciding how business change can be introduced to best effect

bauVsPm

As the pace of change accelerates, management focuses upon striking the balance between BAU and Business change.

 

Projects are the means by which change is introduced and although many managerial skills are the same, there are some crucial differences between BAU and projects.

 

Projects are Important because they implement Change!

 

A project is a temporary organisation created to deliver business products according to an agreed Business Case

Characteristics:

  • Change
Projects are the means by which change is introduced
  • Temporary

Once the desired change is implemented, BAU resumes (in its new form)

Projects should have a defined start and defined end

  • Cross-functional
Working together on a temporary basis with people from different areas and skill sets
  • Unique
i.e. NOT BAU
  • Uncertainty
Due to Risks, Threats and Opportunities

 

Project Management is the Planning, Delegating, Monitoring and Control of all aspects of the project and the Motivation of those involved to achieve the objectives within the expected performance targets for Time, Cost, Quality Scope, Benefits and Risks.

 

It is the development of the project’s deliverables (“products” in PRINCE2 parlance) that deliver the project’s results.

 

The purpose of project management is to keep control over the specialist work required to create the project’s products (e.g. making sure the Linux specialist doesn’t arrive to install the OS and applications before the servers are physically installed into the data centre racks).

What does a Project Manager do?

controlWhat does a Project Manager Do?

 

In order to achieve control, there must be a plan. It is the Project Manager who plans the sequence of events to deliver the project. This can be thought of as being akin to a conductor in an orchestra, who doesn’t necessarily play all the instruments but is well versed in their subtleties and capabilities and knows who should be playing what and very importantly when.

 

The Project Manager delegates the tasks with the intention that everything should “go to plan”. However, this cannot always be relied upon and it is therefore the Project Manager’s responsibility to monitor how well the work in progress matches the plan. If the work does not match the plan, the Project Manager has to do something about it -- either positively (i.e. an opportunity to save time/money) or negatively (e.g. taking corrective action).

 

The intention is to make the right information available at the right time to the right people to make the right decisions.

The 6 Variables

The six variables
1.    Scope

  • Defines what the project will deliver
  • Need to understand what is IN scope and what is OUT of scope
  • Essential that this is very clearly understood and agreed to by all involved parties
  • Without knowing, those involved will make assumptions and often talk at cross-purposes
  • Scope Creep -- Care must be taken not to deliver beyond the scope, as this often causes delays, overspends and uncontrolled changes

variables
2.    Timescales

  • When will the project deliver?

 

3.    Quality

  • Ensuring the deliverables are fit for purpose and meet the defined acceptance criteria

 

4.    Costs

  • Ensuring the project is affordable and within tolerance defined within the Business Case

 

5.    Risk

  • Understanding how much risk can be accepted
  • How can the risks be mitigated?

 

6.    Benefits

  • Why are we doing this?
  • The Project Manager must understand the purpose of the project as an investment and make sure that what the project delivers is consistent with achieving the desired return

 

Structure of PRINCE2

Structure of PRINCE2

 

The PRINCE2 methodology comprises of four integrated elements of:

 

1.    The Principles

  • Guidelines that determine whether the project is being run according to PRINCE2

 

2.    The Themes

  • Describes the aspects that must be continually addressed, in parallel throughout the project

 

3.    The Processes

  • Describe the steps required throughout the project lifecycle
  • Each process provides checklists of recommended activities, products and related responsibilities

 

4.    Tailoring PRINCE2 to the project environment

  • Defines the need to tailor PRINCE2 to the specific context of the project
  • PRINCE2 is not a ‘one size fits all’ -- more so, a flexible framework that can be tailored to any type or size of project

 

p2Structure

Principles

7principles4PRINCE2 Principles are characterised as:

  • Universal in that they apply to every project
  • Self-validating in that they have been proven in practice over many years
  • Empowering because they give practitioners of the method added confidence and ability to influence and shape how the project will be managed

 

The 7 Principles

  1. Continued Business Justification
  2. Learn from Experience
  3. Defined Roles & Responsibilities
  4. Manage by Stages
  5. Manage by Exception
  6. Focus on Products
  7. Tailor to suit the project environment

 

1.    Continued Business Justification

  • A PRINCE2 project has continued business justification, and requires that:
    • There is a justifiable reason to start
    • Justification should remain valid throughout the life of the project
    • Justification is documented and approved

Justification is documented within a Business Case and drives the decision making process to ensure the business objectives and benefits are realised.

 

Failure to have a business case can result in multiple projects having mutually inconsistent or duplicated objectives -> wasted resources, trying to do the same thing.

 

If the project can no longer be justified it must be stopped and should be seen as a positive contribution whereby further resources are not wasted and can thus be reinvested elsewhere in more worthwhile ventures.

 

 

2.    Learn from Experience

  • PRINCE2 project teams learn from experience:
    • Lessons are sought, recorded and acted upon throughout the life of the project
  • When starting a project, previous lessons should be reviewed to see if lessons learned can be applied.
  • As the project progresses, the project should continue to learn and be included in all reports and reviews, with the intention of seeking opportunities to implement improvements
  • As the project closes, the project should pass on lessons

It is the responsibility of all those involved with the project to seek lessons learned rather than waiting for someone else to provide them.

 

 

3.    Defined Roles & Responsibilities

  • A PRINCE2 project has defined and agreed Roles & Responsibilities within an organisational structure that engages the business, users and supplier stakeholder interests
  • Projects involve people. No amount of good planning or control will help if the wrong people are involved, if the right people are not involved or if people do not know what’s expected of them or what to expect of others
  • Projects must have an explicit project management team structure consisting of defined roles and responsibilities for all people involved with the project and a means for effective communication between them

 

All projects have the following primary stakeholders:

  • Business sponsors who endorse the objectives and ensure that the business investment provides value for money
  • Users who, after the project is completed, will use the products to enable them to gain the intended benefits
  • Suppliers who provide the resources and expertise required by the project

A defined project management team structure answers the question: “What is expected of me?”

 

 

4.    Manage by Stages

  • A PRINCE2 project is planned, monitored and controlled on a stage by stage basis
  • Management stages prove senior management with control points at major intervals throughout the project
  • At the end of each stage, the project’s status should be assessed, the Business Case and plans reviewed to ensure that the project remains viable, leading to a decision as to whether to proceed
  • This allows control according to the business priority, risk and complexity involved
  • Planning should only be carried out to a level of detail that is manageable and foreseeable
  • Effort should not be wasted on attempts to plan beyond a sensible planning horizon
    • e.g. a detailed plan for the next 12 months will almost certainly be inaccurate after just a few weeks
  • A detailed plan for the short term and an outline plan for the long term is more effective
  • PRINCE2 overcomes the planning horizon issue by:
    • Dividing the project into a number of stages
    • Having a High-Level Project Plan and a detailed Stage Plan (for the current stage)
    • Planning, Delegating Monitoring and Controlling on a stage by stage basis
  • PRINCE2 requires there to be a minimum of two management stages:
    • One Initiation Stage, and
    • One or more further management stages

 

5.    Manage by Exception

  • A PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority
  • PRINCE2 enables appropriate governance by defining responsibilities for directing, managing and delivering the project and clearly defining accountability at each level
  • Accountability is established by:
    • Delegating authority from one management level to the next by setting tolerances against six objectives for the respective level of the plan:
      • Time    +/- an amount of time on the target completion dates
      • Cost    +/- an amount of the planned budget
      • Quality +/- degrees off a quality target (e.g. product weighs 300g, with an allowed -5 to +10g tolerance)
      • Scope  Permissible variation of the plan’s products (e.g. mandatory requirements +/- desirable requirements)
      • Risk     Limits on the plan’s aggregated risks (e.g. costs of aggregated threats to remain less than 10%of the plan’s budget)
      • Benefit +/- degrees off an improvement goal (e.g. 30-40% cost reduction)
    • Setting up controls so that if those tolerances are forecast to be exceeded, they are immediately referred up to the next management layer for a decision on how to proceed
    • Implementing an assurance mechanism so that each management layer can be confident that such controls are effective
  • The implementation of Management by Exception provides a very efficient use of senior management’s time as it reduces their time burden without removing their control by ensuring decisions are made at the right level in the organisation

 

6.    Focus on Products

  • A PRINCE2 project focuses on the definition and delivery of products, in particular their quality requirements
  • A successful project is output-oriented not activity oriented
  • An output-oriented project is one that agrees and defines the project’s products prior to undertaking the activities required to produce them
  • The set of agreed products defines the scope of a project and provides the basis for planning and control
  • The purpose of a project is to fulfil stakeholder expectations in accordance with the business justification, and to do this there must be a common understanding of the products required and the quality expectations for them
  • A PRINCE2 project uses Product Descriptions to provide such clarity by defining each product’s purpose, composition, derivation, format, quality criteria and quality method
  • They provide the means to determine effort estimates, resource requirements, dependencies and activity schedules
  • The ‘product focus’ supports almost every aspect of PRINCE2: planning, responsibilities, status reporting, quality, change control, scope, configuration management, product acceptance and risk management
  • Without a product focus, projects are exposed to several major risks such as acceptance disputes, rework, uncontrolled change (‘scope creep), user dissatisfaction and underestimation of acceptance activities

 

7.    Tailor to suit the project environment

  • PRINCE2 is tailored to suit the project’s environment, size, complexity, importance, capability and risk.
  • The value of PRINCE2 is that it is a universal project management method that can be applied regardless of project type, organization, geography or culture
  • If PRINCE2 is not tailored, it is unlikely that the project management effort and approach are appropriate for the needs of the project. This can lead to ‘robotic’ project management at one extreme (the method is followed without question) or ‘heroic’ project management at the other extreme (the method is not followed at all)
  • The purpose of tailoring is to:
    • Ensure the project management method relates to the project’s environment (e.g. aligning the method to the business processes that may govern and support the project, such as human resources, finance and procurement)
    • Ensure that project controls are based on the project’s scale, complexity, importance, capability and risk (e.g. the reporting and reviewing frequency and formality)
  • Tailoring requires the Project Manager and the Project Board to make an active decision on how the method will be applied, for which guidance is provided
  • When tailoring PRINCE2, it is important to remember that it requires information (not necessarily documents) and decisions (not necessarily meetings)
  • To ensure that all those people involved with the project understand how PRINCE2 is to be used, the Project Initiation Documentation should state how the method is being tailored for that particular project

Themes

themesThe PRINCE2 themes describe 7 fundamental aspects of project management that must be continually addressed.

 

It is important that the themes are tailored up or down according to the scale, nature and complexity of the project.

 

Business Case

All projects are based on an idea that has potential value for the organization. The Business Case theme addresses how this idea can be developed and converted into a viable investment and business solution. It helps the Project Manager stay focused on the business objectives throughout the project and it answers the questions:

  • Why are we doing this project?
  • What are the benefits and the return?

 

Organisation

For a project to be successful, clear accountabilities must be allocated to managers of the organization so that they can steer the project through to

completion. As projects are cross-functional normal line structures are not suitable. The Organization theme defines the roles and responsibilities on the
project and helps answer the questions:

  • Who does what?
  • Who are the stakeholders?
  • How do we effectively communicate with them?

 

Quality

The Quality theme explains how to develop the initial idea of the project into specific quality attributes and ensure that everyone on the team understands exactly what the project needs to deliver. The theme also explains how project management can subsequently make sure that the specified requirements are delivered. It answers the questions:

  • What level of quality do we need?
  • How do we plan and control quality?

 

Plans

A PRINCE2 project contains a series of approved plans that match the various levels of the project organization. The Plans theme describes the steps required to develop these plans along with the PRINCE2 techniques that should be applied. These plans are the focus for communication and control throughout the project. The Plans theme asks the questions:

  • How is it done?
  • How much resource do we need?
  • When do we finish?

 

Risk

Projects typically entail more risk than steady day to day activities. The Risk theme addresses how project management addresses and mitigates the uncertainties in the project’s plans and in the wider project environment. It answers the questions:

  • What if a certain event happens?
  • How are risks managed?
  • How to Report Risks?

 

Change

The Change theme describes how project management handles issues that have the potential to impact any of the baseline aspects of the project, i.e. the project’s plans and completed products. When we say “issues” we mean general problems, requests for changes or quality failures. The Change theme answers the questions:

  • What is the impact of this change?
  • What is the procedure for documenting and handling issues?

 

Progress

The Progress theme makes sure that the necessary controls and monitoring mechanisms are in place and that the project’s plans are still viable. It explains the decision-making process for approving plans, monitoring performance and escalating issues if events don’t go according to plan. Ultimately, this theme determines whether and how the project should progress. It answers the questions:

  • Where are we now?
  • Where are we going?
  • Should we carry on?

Business Case

The Business Case is one of the most important project management documents that exists in a PRINCE2 project, containing the relevant and optimum mix of information to judge whether the project is, and remains, viable and achievable and is therefore worth investing in.

 

The Project Board and Stakeholders must have confidence at all times that the project remains viable and since its viability is ongoing the Business Case is not static and must therefore be actively updated with current information on costs, risks and benefits throughout the project’s lifecycle.

 

  • Provides Business Justification
  • Developed at the start
  • Maintained throughout
  • Reviewed at End Stage Assessments
  • Defines:
    • Reason for the Project
    • Expected Benefits
    • Estimated Costs
    • Timescales
    • Risks
    • Viability
    • Achievability
    • R.O.I Calculations
  • Drives Decision Making
  • Answers the questions:
    • Is the continued investment in this project still worthwhile?
    • If so, the Project Manager will inform the Project Board on how to continue
    • If not, (e.g. the R.O.I is no longer probable) the Project Manager will recommend to the Project Board that the project should be stopped

 

Outputs, Outcomes and Benefits in PRINCE2:

  • A project’s Output is any of the project’s specialist products (whether tangible or intangible)
  • An Outcome is the result of the change derived from using the project’s outputs
  • A Benefit is the measurable improvement resulting from an outcome that is perceived as an advantage by one or more stakeholders

Example of Outputs, Outcomes and Benefits

 Output: New Sales System
 Outcome: Sales orders are processed more quickly and accurately
 Benefit: Costs are reduced by 10%, volume of sales orders increased by 15% and revenue increased by 10% annually

 

 

Development of the Business Case

In PRINCE2, the Business Case is developed at the beginning of the project and maintained throughout the life of the project, being formally verified by the Project Board at each key decision point, such as end stage assessments, and confirmed throughout the period that the benefits accrue.

 

In this context:

  • Develop means getting the right information upon which decisions can be made
  • Verify means assessing whether the project is (still) worthwhile
  • Maintain means to update the Business Case with actual costs and benefits and current forecasts for costs and benefits
  • Confirm means assessing whether the intended benefits have been (or will be) realized. Confirming benefits will mostly take place postproject.

 

Developing the Business Case

The Project Executive is responsible for creating the Business Case and ensuring that the benefits defined by the Senior User represent value for money, are aligned to corporate objectives and are capable of being realised.

 

 

Although development of the Business Case can be delegated it is essential that whoever is writing it has the appropriate business skills and acumen (e.g. understanding of profit and loss, balance sheets, cashflow forecast).

 

The outline Business Case is derived from the Project Mandate (the trigger for the project) which should also contain information on the Business Case in terms of why the project is needed. In the Starting-Up process, the Business Case information is taken from the Project Mandate and copied to the outline Business Case in the Project Brief where it is elaborated on. The Project Brief is then presented to the project board for authorization.

 

During the Initiation Stage, the outline Business Case is extended into the full Business Case document where it becomes part of the PID (Project Initiation Documentation).

bc2

Verifying and Maintaining the Business Case

The Business Case drives all decision making by ensuring that the project remains justified and that the business objectives and benefits being sought can be realized, and should therefore be reviewed:

  • At the end of the Starting up a Project process by the Project Board in order to authorize project initiation based on a reasonable justification
  • At the end of the Initiating a Project process by the Project Board in order to authorize the project
  • As part of any impact assessment by the Project Manager of any new or revised issues or risks
  • In tandem with an Exception Plan by the Project Board, in order to authorize the revised stage and the continuation of the project
  • At the end of each stage by the Project Manager to determine whether any of the costs, timescales, risks or benefits need to be updated
  • At the end of each stage by the Project Board, to authorize the next stage and the continuation of the project
  • During the final stage by the Project Manager, to assess the project’s performance against its requirements and the likelihood that the outcomes will provide the expected benefits
  • As part of the benefits review (possibly by corporate or programme management), to determine the success of the project outcomes in realizing their benefits

 

Confirming the Benefits

  • Identify the benefits
  • Select objective measures that reliably prove the benefits
  • Collect baseline measures (from which the improvements will be quantified)
  • Decide how, when and by whom the benefit measures will be collected

The Senior User(s) specifies the benefits and is held to account by demonstrating to corporate or programme management that the forecast benefits that formed the basis of project approval are in fact realized. This may involve a commitment beyond the life of the project as it is likely that many benefits will not be realized until after it has closed.

 

By default, the Executive is responsible for ensuring that benefits reviews are planned and executed, but there are circumstances where this may not always be the case:

  • For projects in a programme environment, the project’s Benefits Review Plan may be produced and executed by the programme, as one of the roles of the programme is to coordinate the realization of the benefits of its projects
  • If the corporate organization has a centre of excellence or some form of performance monitoring unit, it may undertake the responsibility for measuring benefits of all projects within the organization
  • For post-project measurement activities, the responsibility for benefits reviews will transfer from the Executive to corporate or programme management as the project closes (as the reviews will need to be funded and resourced)

The Benefits Review Plan is first created by the Project Manager in the initiation stage and is submitted to the Project Board for approval when seeking project authorization. It is then updated towards the end of each stage with actual benefits achieved, and a revised plan is created for any remaining reviews whether within or beyond the life of the project.

 

Contents of a Business Case

The Business Case should describe the reasons for the project based on estimated costs, risks and expected benefits. It typically contains:

  • Executive Summary
  • Reasons
    • Explains why the project is required
  • Business options
    • Do nothing (should always be considered)
    • Do the minimum
    • Do something
  • Expected Benefits
    • List each benefit expected to be achieved
    • Defining the current status of each benefit in quantifiable terms (so they can be measured, and tolerances set)
    • Define how and when each benefit can be measured
  • Expected Dis-benefits (really! who thought up that word -- gah!! -> Drawback, Disadvantage)
    • An outcome perceived as negative by one or more stakeholders
    • Consequences of actual activity (A.K.A Issues) as opposed to Risks (that are uncertain whether they will arise)
  • Timescales
    • Period over which project costs will be incurred
    • Period over which Costs/Benefits analysis will be based
    • When Benefits are expected
    • Earliest / Latest feasible Start date
    • Earliest / Latest feasible Completion date
    • Helps identify tolerances and timings for benefits review
  • Costs
    • Derived from the Project Plan (including assumptions upon which they are based)
    • Should include ongoing Operations and Maintenance costs (and their funding arrangements)
  • Investment Appraisal
    • Comparison of the development, operations and maintenance costs with the value of the benefits over a period of time (A.K.A Investment Appraisal)
    • Should cover the cost of doing the project along with the ongoing Operations and Maintenance costs
  • Major Risks
    • A summarised Risk Profile highlighting the major risks that will have an effect on the business objectives and benefits
    • Should cover the project delivery along with the ongoing Operations and Maintenance aspects

 

Responsibilities

Responsibilities relevant to the Business Case

Corporate or

Programme

Management

  • Provide the project mandate and define any standards to which the Business Case needs to be developed
  • Hold the Senior User(s) to account for realizing the post-project benefits enabled by the project’s products
  • Responsible for the Benefits Review Plan (post-project)
Executive
  • Responsible for the Business Case for the duration of the project
  • Responsible for the Benefits Review Plan (for the duration of the project) unless being managed by corporate or programme management
  • Oversee the development of a viable Business Case, ensuring that the project is aligned with corporate strategies, and secure the funding for the project
Senior User(s)
  • Responsible for specifying the benefits upon which the Business Case is approved
  • Ensure the desired outcome of the project is specified
  • Ensure that the project produces products which deliver the desired outcomes
  • Ensure that the expected benefits (derived from the project’s outcomes) are realized
  • Provide actual versus forecast benefits statement at the benefits reviews
Senior Suppliers
  • Responsible for the supplier Business Case(s) (if they exist)
  • Confirm that the products required can be delivered within the expected costs and are viable
Project Manager
  • Conduct impact analysis of any new or revised issues or risks that affect the project’s desirability, viability or achievability against the original basis for approving the project
  • Assess and update the Business Case at the end of each management stage
  • Assess and report on project performance at project closure

Project Assurance

(business assurance responsibilities)

  • Assist in the development of the Business Case
  • Verify and monitor the Business Case against external events and project progress
  • Ensure the project fits with overall programme or corporate strategy
  • Monitor project finance on behalf of the customer
  • Ensure the value-for-money solution is constantly reassessed
  • Monitor changes to the Project Plan to identify any impact on the needs of the business or the Business Case
  • Review the impact assessment of potential changes on the Business Case and Project Plan
  • Verify and monitor the Benefits Review Plan for alignment to corporate or programme management
Project Support
  • The Business Case should have a baseline and therefore be under configuration management. Project Support should advise the Project Manager of any proposed or actual changes to products that affect the Business Case

Investment Appraisal Techniques

Through Life Costs
  • Through-life costs Analysing the total cost of implementation and any incremental operations and maintenance costs
Net Benefits
  • Analysing the total value of the benefits less the cost of implementation and ongoing operation calculated over a defined period

ROI (Return on

investment)

  • Profits or savings resulting from investments (this is the same as net benefits if the benefits were only financial)
Payback Period
  • Calculating the period of time required for the ROI to ’repay’ the sum of the original investment
Discounted Cash Flow
  • A means of expressing future benefits based on the current value of money
  • Sometimes discounted cash flows include risk adjustments as the business may not be confident that all the benefits will materialize
Net Present Value
  • The total value of discounted future cash inflows less the initial investment
  • For example, if inflation is at 6%, the value of money halves approximately every 12 years. If a project is forecasting a £500,000 benefit to materialize in year 12, then it is only worth £250,000 in today’s money
Sensitivity Analysis
  • Business Cases are based on uncertain forecasts
  • In order to identify how robust the Business Case is, it is useful to understand the relationship between input factors (e.g. project costs, timescale, quality, scope, project risk) and output (e.g. operations and maintenance costs, business benefits and business risk)
  • Sensitivity analysis involves tweaking the input factors to model the point at which the output factors no longer justify the investment
  • For example, the project is worthwhile if it can be done in four months, but ceases to be worthwhile if it were to take six months

 

Organisation

The purpose of the Organization theme is to define and establish the project’s structure of accountability and responsibilities.

 

PRINCE2 is based on a customer/supplier environment. It assumes that there will be a customer who will specify the desired result and probably pay for the project, and a supplier who will provide the resources and skills to deliver that result.

 

One of the principles of PRINCE2 is that all projects must have a defined organizational structure to unite the various parties in the common aims of the project and to enable effective project governance and decision making.

 

A successful project management team should:

  • Have business, user and supplier stakeholder representation
  • Ensure appropriate governance by defining responsibilities for directing, managing and delivering the project and clearly defining accountability at each level
  • Have reviews of the project roles throughout the project to ensure that they continue to be effective
  • Have an effective strategy to manage communication flows to and from stakeholders

 

PRINCE2 defines a project as “a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case”. It needs to be flexible and is likely to require a broad base of skills for a comparatively short period of time.

 

Three project interests

The PRINCE2 principle of defined roles and responsibilities states that a PRINCE2 project will always have three primary categories of stakeholder, and the interests of all three must be satisfied if the project is to be successful.

 

projInterestsPRINCE2 recommends that for completeness the Project Board should include representation from each of the business, user and supplier interests at all times:

 

  • Business The products of the project should meet a business need which will justify the investment in the project. The project should also provide value for money. The business viewpoint therefore should be represented to ensure that these two prerequisites exist before a project commences and remain in existence throughout the project. The Executive role is defined to look after the business interests
  • User PRINCE2 makes a distinction between the business interests and the requirements of those who will use the project’s outputs. The user viewpoint should represent those individuals or groups for whom some or all of the following will apply:
    • They will use the outputs of the project to realize the benefits after the project is complete
    • They will operate, maintain or support the project’s outputs
    • The outputs of the project will impact them
  • The user presence is needed to specify the desired outputs and ensure that the project delivers them. The Senior User(s) will represent this stakeholder interest on the Project Board
  • Supplier The creation of the project’s outputs will need resources with certain skills. The supplier viewpoint should represent those who will provide the necessary skills and produce the project product. The project may need to use both in-house and external supplier teams to construct the project product. The Senior Supplier(s) will represent this stakeholder interest on the Project Board.

 

Levels of Organisation

Since senior management may not be available on a day to day basis to make decisions, PRINCE2 separates the direction and management of the project from the delivery of the project’s outputs, by using the principle of Management by Exception.

 

The project management structure has four levels, three which represent the project and Corporate sitting outside of the project:prjMgmtTeamStructure

 

  • Corporate. Responsible for:
    • Commissioning the project
    • Appointing the Executive
    • Defining project level tolerances, for the project board
    • All this information should be documented in the Project Mandate
  • Directing. The Project Board is responsible for:
    • Overall direction & management
    • Accountable for success of the project
    • Approve all major plans
    • Authorise any deviation that exceeds tolerance
    • Approve completion of each stage
    • Authorise start of next stage
    • Communicate with other stakeholders
  • Managing. The Project Manager is responsible for:
    • Day to day management of the project within constraints set by the Project Board
    • Ensure the require products are delivered in accordance with the time, cost, quality, scope risk and benefit goals
  • Delivering. The Team Managers are responsible for:
    • Delivering the project’s products to an appropriate quality within a specified timescale and cost

 

Project Management Team Structure

A project management team is a temporary structure specifically designed to manage the project through to its successful delivery.

 

The Project Board has the authority  and responsibility for the project within the instructions (initially contained in the project mandate) set by corporate or programme management. Their duties include:

  • Accountability for success or failure
  • Providing a unified view
  • Delegating effectively
  • Facilitating integrating the project management team with the participating parts of the business
  • Providing the resources and authorising the funds required
  • Effective decision making
  • Providing visible and sustained support for the Project Manager
  • Ensuring effective communication with all stakeholders

The Executive is appointed by Corporate or Programme management during the pre-project process of starting up a project. The role is vested in one individual so that there is singular accountability for the project. The Executive’s role is to:

  • Design & appoint the rest of the project management team, including the other members of the board
  • Provide responsibility for the Business Case
  • Ultimately be accountable for the project’s success and is the key decision maker
  • Ensure the project is focussed on achieving its objectives and delivering a product that will achieve the forecasted benefits
  • Ensure that the project gives value for money, balancing the demands of the business, user and supplier

The Senior User is responsible for:

  • Specifying the needs of those who will use the project’s products (A.K.A deliverables)
  • User liaison with the project management team
  • Monitoring that the solution will meet the needs within the constraints of the Business Case in terms of quality, functionality and ease of use.
  • Committing User resources
  • Specifying the benefits
  • Demonstrating that the forecast benefits were realised

The Senior Supplier represents those designing, developing, facilitating, procuring and implementing the project’s products and is also responsible for:

  • Accountability for the quality of the products
  • The technical integrity of the project
  • Ensuring that proposals for designing and developing the products are feasible and realistic

The Project Board also has a Project Assurance role that is:

  • Responsible for all aspects of the project’s performance and products independently of the Project Manager
  • Aligned to their respective areas of concern -- business, user or supplier
  • Accountable for the quality aspects of the project
  • Responsible for supporting the Project Manager by providing advice and guidance to the on issues such as the use of corporate standards or
    the correct personnel to be involved in different aspects of the project
  • Independent from the Project Manager and should not assign any Project Assurance roles to the Project Manager

 

Change Authority

At project initiation, consideration should be taken as to who is permitted to authorise requests for change or off-specifications. The Project Board has the responsibility to agree each potential change before it is implemented. The Project Board should define in the Configuration Management Strategy a scale of severity ratings for requests for change and, depending on the severity, the request for change could be handled by:

  • Corporate or programme management
  • The Project Board
  • Delegating to a Change Authority
  • Delegating to the Project Manager

 

Example of a change Authority

A Project Manager is given authority to approve changes to individual products only if the changes would:

  • Cost less than a pre-arranged limit
  • Impact the project timescales by no more than one week
  • Not require any changes to the Project Product Description or any other product

Any changes that fall outside of these limits would have to be escalated to the Project Board

 

Reporting Structure

The Executive is responsible for agreeing a suitable team structure and tailoring it to the project’s size, risk and complexity. The Project Board needs to:

  • Represent the needs of all interested parties and involve any (internal or external) suppliers
  • Be kept as small as possible (to allow appropriate and timely decision making)

reportingStructure2

Producing a matrix of stakeholders against the project’s products also helps split the project stakeholders (who need to be engaged as part of the Communication Management Strategy) from the project decision makers (who need to be on the Project Board).

 

 

Project ManagerprojMgr

The Project Manager:

  • Is the single focus for the day to day management of a project
  • Has the authority to run the project on behalf of the Project Board within the constraints laid down by the Project Board
  • Role should not be shared
  • Is responsible for the work of all the PRINCE2 processes except for the Directing a Project process and appointing the Executive and the Project Manager in the pre-project process Starting up a Project
  • Delegates responsibility for the Managing Product Delivery process to the Team Managers
  • Manages the Team Managers and Project Support and is responsible for liaison with Project Assurance and the Project Board

In projects with no separate individual allocated to a Team Manager role, the Project Manager will be responsible for managing work directly with the team members involved. In projects with no separate Project Support role, the support tasks also fall to the Project Manager, although they may be shared with team members.
As the single focus for the day-to-day management of a project, there are many different aspects to the Project Manager role!

 

 

Team Manager

The Team Manager:

  • Ensure production of the product’s allocated by the Project Manager
  • Reports to and takes direction from the Project Manager
  • Role CAN be assigned to the the Project Manager
  • Uses Work Packages to allocate work to Team Managers / members

 

Project Support

Project Support is the responsibility of the Project Manager, who can delegate some of this work to a project Support role:

  • Administrative services
  • Advice / guidance
  • Project planning
  • Risk Management
  • Administering the Configuration Management tools and procedures

Project Support and Project Assurance roles should be kept separate in order to maintain the independence of Project Assurance.

 

 

Stakeholders

Individuals or groups that are not part of the project management team, but who may need to interact with the project, may be affected by the project’s outcome. These people may:

  • Support or oppose the project
  • Gain or lose as a result of the project delivery
  • See the project as a threat or enhancement to their position
  • Become active supporters or blockers of the project and its progress

It is therefore important to analyse who these stakeholders are and to engage with them appropriately.

 

Stakeholder engagement, is the process of identifying and communicating with those who have an interest or influence on the project’s outcome.

Example of Stakeholder Engagement

  • Identifying stakeholders (Who?) Identifying the individual stakeholders involved in, or affected by, the project and perhaps grouping similar stakeholders together so that key messages can be targeted effectively
  • Creating and analysing stakeholder profiles (What?) Gaining an understanding of the influences, interests and attitudes of the stakeholders towards the project and the importance and power of each stakeholder. For instance, is a particular group likely to be negative, irrespective of the message, and therefore require particular care? Stakeholders’ influence and interests, whether rational or emotional, must all be taken into account. They have the potential to affect the success of the project. Perceptions may be mistaken, but they must be addressed. The stakeholder’s perception of the benefits should be quantified where possible
  • Defining the stakeholder engagement strategy (How?) Defining how the project can effectively engage with the stakeholders, including defining the responsibilities for communication and the key messages that need to be conveyed. For each interested party, agree the:
    • Information the party needs from the project
    • Method, format and frequency of communication
    • Sender and recipient of the communication
  • Planning the engagements (When?) Defining the methods and timings of the communications. These are best planned after defining how the project will engage with the different stakeholders. When selecting the senders of information, it is important to select communicators who have the respect and trust of the Audience. Their position in the corporate organization and expertise in the subject matter will greatly influence their credibility. Many projects have a formal commencement meeting to introduce the project and its aims to the corporate organization. If this type of meeting is used, it is important that the members of the Project Board attend to show their support and commitment to the project
  • Engaging stakeholders (Do) Carrying out the planned engagements and communications. The first two steps in stakeholder engagement – identifying and analysing – also engage stakeholders to some degree
  • Measuring effectiveness (Results) Checking the effectiveness of the engagements. Project Assurance could be involved in checking all the key stakeholders, their information needs and that the most appropriate communication channels are covered.

 

 

The Communication Management Strategy

The Communications Management strategy contains a description of the means and frequency of communication to all (internal and external) parties involved with the project and facilitates engagement with stakeholders through the establishment of a controlled and bi-directional flow of information.

 

The Project Manager is responsible for  creating the Communication Management Strategy, which should also be reviewed and updated (if necessary) at each stage boundary to ensure it includes all the key stakeholders.

Responsibilities relevant to the Organisation theme

Role Responsibilities

Corporate or

Programme Management

  • Appoint the Executive and (possibly) the Project Manager
  • Provide information to the project as defined in the Communication Management Strategy
Executive
  • Appoint the Project Manager (if not done by corporate or programme management)
  • Confirm the appointments to the project management team and the structure of the project management team
  • Approve the Communication Management Strategy
Senior User
  • Provide user resources
  • Define and verify user requirements and expectations
Senior Supplier
  • Provide supplier resources
Project Manager
  • Prepare the Communication Management Strategy
  • Review and update the Communication Management Strategy
  • Design, review and update the project management team structure
  • Prepare role descriptions
Team Manager
  • Manage project team members
  • Advise on project team members and stakeholder engagement
Project Assurance
  • Advise on selection of project team members
  • Advise on stakeholder engagement
  • Ensure that the Communication Management Strategy is appropriate and that planned communication activities actually take place
Project Support
  • Provide administrative support for the project management team

 

Quality

The PRINCE2 Quality theme:

 

  1. Provides a common understanding of what the project will create = the Scope
  2. Defines the Acceptance Criteria which the project’s products will be assessed = the Quality
  3. Thus ensuring that products are fit for purpose
  4. Meet the quality expectations of customers and users
  5. Defines the Quality Management activities, required in the project’s plan
    1. This allows the full project cost and timescales to be estimated
    2. If omitted / overlooked is likely to lead to slippages, overspends and/or poor quality results
  6. Covers Continuous Improvement during the project
    1. e.g. to introduce more efficiency into the management of the project and it’s products
    2. Capturing & acting upon Lessons Learned

What is Quality?

Quality is generally defined as the totality of features and inherent or assigned characteristics of a product, person, process, service and/or system that bear on its ability to show that it meets expectations or satisfies stated needs, requirements or specification.
In PRINCE2, a product can also be a person, process, service and/or system, so the focus of quality is on a product’s ability to meet its requirements.

 

 

Scope

The scope of a plan is the sum total of its products. It is defined by the product breakdown structure for the plan and its associated Product Descriptions.

 

 

Quality Management and Quality Management Systems

Quality management is defined as the coordinated activities to direct and control an organization with regard to quality.

 

A quality management system is the complete set of quality standards, procedures and responsibilities for a site or organization. In the project context, ‘sites’ and ‘organizations’ should be interpreted as the permanent or semipermanent organization(s) sponsoring the project work, i.e. they are external to the project’s temporary organization.

 

 

Quality Planning

To control anything, including quality, there must be a plan. Quality planning is about defining the products required of the project, with their respective quality criteria, quality methods (including effort required for quality control and product acceptance) and the quality responsibilities of those involved.

 

Quality control

Quality control focuses on the operational techniques and activities used by those involved in the project to:

  • Fulfil the requirements for quality (for example, by quality inspections or testing)
  • Identify ways of eliminating causes of unsatisfactory performance (for example, by introducing process improvements as a result of
    lessons learned)

 

Quality Assurance

Quality Assurance provides a check that the project’s direction and management are adequate for the nature of the project and that it complies with relevant corporate or programme management standards and policies. Quality assurance activities are outside the scope of PRINCE2 as it is the responsibility of the corporate or programme organization.

 

Quality Assurance is about independently checking that the organization and processes are in place for quality planning and control (i.e. not actually
performing the quality planning or control, which will be undertaken by the project management team). It provides the project’s stakeholders with confidence that the quality requirements can be fulfilled.
The term ‘quality assurance’ is used in two senses:

  • As the function within an organization (or site or programme) that establishes and maintains the quality management system
  • As the activity of reviewing a project’s organization, processes and/or products to assess independently whether quality requirements will be met

 

The PRINCE2 approach to Quality

The specific treatment for quality in PRINCE2 is the focus on products from the outset, requiring systematic activities to:

  • Identify all the project’s products (i.e. to the level at which the project intends to exert control)
  • Define them in Product Descriptions – including the quality criteria by which they will be assessed; the quality methods to be used in
    designing, developing and accepting them; and the quality responsibilities of those involved
  • Implement and track the quality methods employed throughout the project

The first two of these are covered by quality planning and the last is covered by quality control and quality assurance.

 

The figure to the right shows the Quality Audit Trail:

 

Quality Planning ensures:

  • Project Board agreement on the overall quality expectations, the products required with their associated quality criteria (including corporate and other standards to be observed), the means by which quality will be achieved and assessed and, ultimately, the acceptance criteria by which the project’s product will be judged
  • Communicating these agreements unambiguously so that all the project stakeholders have a common understanding of what the project is setting out to achieve
  • Control, i.e. establishing an effective baseline for the project’s quality controls (including the quality tolerances) and a secure means of achieving products that are fit for purpose

Quality Planning comprises:

  • Understanding the customer’s quality expectations
  • Defining the project’s acceptance criteria
  • Documenting the customer’s quality expectations and the project’s acceptance criteria in the Project Product Description
  • Formulating a Quality Management Strategy
  • Writing clear Product Descriptions containing quality criteria, quality tolerances, quality method and quality responsibilities
  • Setting up the Quality Register

The Customer’s Quality Expectations are a statement about the quality expected from the project product. They are defined and agreed early in the Starting up a Project process. The expectations are captured in discussions with the customer and then refined for inclusion in the Project Product Description. To avoid misinterpretations and inaccurate assumptions about the project’s quality requirements, the customer’s quality expectations should cover:

 

  • The key quality requirements for the project product
  • Any standards and processes that will need to be applied to achieve the specified quality requirements, including the extent to which the customer’s and/or supplier’s quality management system should be used
  • Any measurements that may be useful to assess whether the project product meets the quality requirements (for example, existing customer satisfaction measures)

Example of Quality Expectation

The quality expectation for a water pump in a remote village is that it is robust enough to ‘last a lifetime’, whereas because the oil pump in a racing car needs to be as light as possible, it may only need to last the duration of one race.

 

 

The project’s Acceptance Criteria form a prioritized list of measurable definitions of the attributes required for a set of products to be acceptable to
key stakeholders. Examples are ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs,
capacity, availability, reliability, security, accuracy, and performance.
Acceptance Criteria should be prioritized as this helps if there has to be a trade-off between some criteria – high quality, early delivery and low cost, for example, may not be compatible and one of them may need to be sacrificed in order to achieve the other two.

Example of a prioritization technique – MoSCoW

Each Acceptance Criterion is rated as either Must have, Should have, Could have or Won’t have for now (MoSCoW).

 

All the ‘Must have’ and ‘Should have’ Acceptance Criteria should be mutually achievable.

When the project can demonstrate that all the Acceptance Criteria have been met, the project’s obligations are fulfilled and the project can be closed. The acceptance criteria should be agreed between the customer and supplier during the Starting up a Project process and documented as part of the Project Product Description. It is important to recognize that little may be understood about the project’s products at this early point.

 

Consequently, it is often the case that acceptance criteria will be refined and agreed during the Initiating a Project process and reviewed at the end of each management stage. Once finalized in the Project Product Description, acceptance criteria are subject to change control and can only be changed with the approval of the Project Board.

Example of Acceptance Criteria

If a customer’s quality expectation for a water pump is that it ‘lasts a lifetime’, the acceptance criteria should focus on those measures that provide sufficient indication or confidence that the pump is capable of lasting a lifetime (defined as a specific number of years). This may include complying with certain engineering standards relating to product durability.

 

 

The Project Product Description is created in the Starting up a Project process as part of the initial scoping activity and may be refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at stage boundaries (during Managing a Stage Boundary) to see if any changes are required. It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it and that the acceptance criteria have been met.

 

The Project Product Description includes:

  • The overall purpose of the product
  • Its composition (i.e. the set of products it needs to comprise)
  • The customer’s quality expectations
  • Acceptance criteria, method and responsibilities
  • Project-level quality tolerances

The approved Project Product Description is included as a component of the Project Brief and is used to help select the project approach. The Project Product Description defines what the customer is expecting the project to deliver and the project approach defines the solution or method to be used by the supplier to create the project product.

 

The Project Product Description is a special form of Product Description in that it includes the customer’s quality expectations and, at this level, the quality criteria and quality methods constitute the acceptance criteria and acceptance methods for the project overall.

 

 

The Quality Management Strategy is prepared during the Initiating a Project process and approved subsequently by the Project Board. It augments the project approach and can be regarded as the project management team’s proposals in response to the customer’s quality expectations and acceptance criteria.

 

The Quality Management Strategy:

  • Describes how the quality management systems of the participating organizations will be applied to the project and confirms any quality standards,procedures, techniques and tools that will be used
  • Where models and standards are to be tailored, the tailoring should also be outlined in the Quality Management Strategy for approval.
  • Provides a means by which the levels of formality to be applied in the quality plans and controls can be scaled and agreed according to the particular needs of the project
  • Outline the arrangements for quality assurance, including independent audits where these are required by the policies of the participating organizations

Key responsibilities for quality should be defined (both within and outside the project management team), including a summary of the approach to Project Assurance. Where there is already an established quality management system for projects, for example in a programme, only the measures specific to this project may need to be documented.

 

The Quality Management Strategy is maintained, subject to change control, throughout the life of the project.

 

 

Once detailed planning gets underway, Product Descriptions should be created for all of the project’s products. Product Descriptions are not optional.  They govern the development of the products and their subsequent review and approval.

 

The level of detail in a Product Description is a matter of judgement, with the primary aim being to select a level that provides a secure and appropriate measure of control sufficient to fulfil the customer’s quality expectations.

 

The purpose section of the Product Description should clearly state who needs the product, why they need it and what it will do. In addition to the purpose, the sections specific to quality are: quality criteria, quality tolerances, quality methods, quality skills required and quality responsibilities.

 

These define the quality controls that must be applied during product development and in the review and approval procedures for the completed product.

 

 

The Product Description should include the quality specifications that the product must meet, and the quality measurements that will be applied by those inspecting the finished product. The Quality Criteria should be of sufficient detail and clarity to enable those reviewing a product to unambiguously confirm whether the product meets its requirements.

 

Quality Tolerances for a product can be specified in quality criteria by defining an acceptable range of values. For example:

  • Is the duration of the presentation 30 minutes (plus or minus 5 minutes)?
  • Is temperature maintained in the range of 1 to 5°C?

Example of Quality Criteria

Consider a project to design and manufacture a new camera. One quality criterion is that the camera and its packaging must weigh no more than 1 kg. The product breakdown structure identifies a user guide product. It follows that the size and weight of the user guide is an important factor and not, for example, the number of pages.

 

Questions to be asked include: What is the target market for the camera? Does this also imply that the manual needs to be written in several languages? Will that mean it gets heavier? Or will a CD-ROM-based manual suffice? This could reduce the weight of the manual and allow the camera itself to be heavier.

 

Considering quality criteria often highlights connections and factors such as these which inform the subsequent planning process.

 

The Quality Methods section of the Product Description is used to specify the quality activities to be implemented during the development of a product, for review and approval on completion. Where specialized skills are implicit in the quality methods, these should also be specified. There are two primary types of quality methods: in-process methods and appraisal methods.
To avoid doubt, the Quality Responsibilities for a product should be specified. The responsibilities will fall into one of three categories:

  • Producer The person or group responsible for developing a product
  • Reviewer(s) A person or group independent of the producer who assesses whether a product meets its requirements as defined in its Product
    Description
  • Approver(s) The person or group, for example a Project Board, who is identified as qualified and authorized to approve a product as being complete and fit for purpose

 

The Quality Register is effectively a diary of the quality events planned and undertaken (for example, workshops, reviews, inspections, testing, pilots, acceptance and audits). It is created during the Initiating a Project process as the products and quality control measures are being defined. It is then maintained (in line with the current baseline plans) throughout the project.

 

 

Quality Control

Quality control is achieved by implementing, monitoring and recording the quality methods and responsibilities defined in the Quality Management Strategy and Product Descriptions (and subsequently agreed to in Work Packages). Quality control comprises:

  • Carrying out the Quality Methods
  • Maintaining quality and approval records
  • Gaining acceptance

 

The cost of correcting flaws in products increases the longer they remain undetected. It is much easier and cheaper to correct a design document early in the project than to correct a design fault that is only discovered when the finished product is being tested or, worse, when the product is already in operational use. It follows that quality inspections, implemented early in the design and development process, are potentially the most cost effective
quality methods available. There are two types of quality methods:

  • ‘In-process’ methods These are the means by which quality can be ’built into’ the products as they are developed. These might involve the use of specialist methods and/or techniques, including calibrated process controls, automation (e.g. robotics, software tools), piloting exercises, workshops, surveys and consultation, or, more simply, the use of quality inspections during the course of product development as well as upon completion
  • Appraisal methods These are the means by which the finished products are assessed for completeness and fitness for purpose. There are, in essence, two types of appraisal methods, depending on the extent to which it is possible to define objective quality criteria: testing (if the quality criteria are truly objective and quantifiable) or quality inspection (if some subjective judgement is required)

A quality inspection is a systematic, structured assessment of a product conducted in a planned, documented and organized fashion. A systematic
but flexible approach to quality inspection can be used:

  • During the development of products of this type, whether formally (i.e. in line with what was agreed during quality planning) or informally (simply as a means of assessing the quality of a ’work in progress’)
  • To mark the completion and approval of products
  • To complement testing, e.g. simply for checking test results

 

 

The PRINCE2 quality review technique

Objectives:

  • To assess the conformity of a product which takes the form of a document (or similar item, e.g. a presentation or test results) against set criteria
  • To involve key interested parties in checking the product’s quality and in promoting wider acceptance of the product
  • To provide confirmation that the product is complete and ready for approval
  • To baseline the product for change control purposes

Review team roles:

  • Chair This role is responsible for the overall conduct of the review
  • Presenter This role introduces the product for review and represents the producer(s) of the product. The presenter also coordinates and tracks the work after the review, i.e. applying the changes to the product agreed by the team
  • Reviewer This role reviews the product, submits questions and confirms corrections and/or improvements
  • Administrator This role provides administrative support for the chair and records the result and actions

The minimum form of review (used for simple inspections, e.g. of test results) involves only two people: one taking the chair and reviewer roles, the other taking the presenter and administrator roles
Note: quality review is a generic technique which can be used outside the project context. Thus the quality review roles have no specific relationship to roles in the project management team structure. However, team-building benefits can be realized where Project and Team Managers regularly chair reviews. Chairing quality reviews requires competence in facilitation and independence of the product being reviewed (the primary responsibility is to ensure that the review is undertaken properly)