P2F Handouts

Introduction Course Topics  Overview - Principles, Themes, Processes and Products  Themes - Business Case (BC), Organization (OR), Quality (QU), Plans (PL), Risk (RK), Progress (PG), Change (CH)  Processes - Starting up a Project (SU), Directing a Project (DP), Initiating a Project (IP), Controlling a Stage (CS), Managing Product Delivery (MP), Managing a Stage Boundary (SB), Closing a Project (CP)  Exam prep Course Topics Flow  Overview  Business Case theme (BC)  Organization theme (OR)  Starting up a Project process (SU)  Directing a Project process (DP)  Initiating a Project process (IP)  Quality theme (QU)  Plans theme (PL)  Risk theme (RK)  Progress theme (PG)  Change theme (CH)  Controlling a Stage process (CS)  Managing Product Delivery process (MP)  Managing a Stage Boundary process (SB)  Closing a Project process (CP)  Exam Prep Course Approach  Discuss topics  Complete a case study  Present and discuss case study  Complete module exam questions  Exam prep at the end of the course Course Materials  Course reference manual, case study, exam questions and final exams About PRINCE2 Qualifications – PRINCE2 Foundation  Sufficient knowledge and understanding of the PRINCE2 method to be able to work effectively with (or as a member of) a project management team working within an environment supporting PRINCE2  Multiple choice examination questions  60 questions per paper  60 minutes  Pass: 33 marks required (out of 60 available) – 55% www.xpmconsulting.com 1

Introduction  Closed book About PRINCE2 Qualifications – PRINCE2 Practitioner  Should (with suitable direction) be able to start applying and customizing the method to a real project – but may not be sufficiently skilled to do this appropriately for all situations.  Multiple choice examination questions  Objective testing  68 questions  38/68 required to pass = 55% pass mark  Two-and-a-half hours’ (150 minutes) duration, no additional reading time  Open book exam (official PRINCE2 manual only).  Requirements: PRINCE2 Foundation, PMP or CAPM Exam Delivery Options  Group exams  Voucher online PRINCE2 Foundation exam question types Which is one of the four A purpose of the [ ? ] Which two statements integrated elements theme is to control any about tailoring are within PRINCE2? unacceptable deviations CORRECT? a) Quality from the project's 1. Processes can be b) Role descriptions objectives. simplified or carried out c) Processes a) Change in more detail. d) Product descriptions b) Plans 2. Terminology can be c) Progress changed to suit d) Risk organizational standards. 3. Themes that are not relevant to the project can be excluded. 4. Project management team members can carry out any combination of roles. a) 1 and 2 b) 2 and 3 c) 3 and 4 d) 1 and 4 Maintaining your Certification  The foundation examination is not valid for a defined period and will not expire.  Individuals remain 'PRINCE2 Registered Practitioners' for a period of 3 years. Must complete and pass a PRINCE2 re-registration examination or maintain certificate through Axelos membership www.xpmconsulting.com 2

Overview of PRINCE2 Project  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  Project Characteristics: Change, Temporary, Cross-functional, Unique and Uncertainty Project Characteristics  Six aspects of project performance (variables) to control: Costs, Timescales, Quality, Scope, Risk and Benefits What does a Project Manager do? Projects Scenarios Projects within Programmes  Programme is a temporary, flexible organisation created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives  Projects deal with Outputs and programmes deal with Outcomes  PRINCE2® (PRojects IN Controlled Environments) is a method for project management  Managing Successful Programmes (MSP®) is a method for programme management Projects within Portfolios  Portfolio is the totality of an organization's investment (or segment thereof) in the changes required to achieve its strategic objectives.  Portfolios may include programmes, projects and other work  Not necessarily related but must contribute to strategic objectives Projects in a Commercial Environmental  Simple customer/supplier relationship; Joint ventures; collaborative research; intergovernmental projects; interagency projects; partnerships www.xpmconsulting.com 3

Overview of PRINCE2 Principles, Themes, Processes and Products What are Principles  A guiding obligation for good practice  Universal – apply to every project  Self-validating – proven in practice over many years  Empowering – adding confidence  Principles: o Defined Roles and responsibilities o Manage by Stages o Manage by exception o Learn from experience o Tailoring o Continued Business Justification o Focus on Products Themes  Aspects of project management that need to be addressed continually  Integrated themes are designed to link together in a chronological flow  7 Themes: o Business Case o Organization o Quality o Plans o Risk o Change o Progress Processes Pre-Project Initiation Subsequent Final Stage Stage Delivery Stages Directing Directing Project Managing Starting Up a Project Initiating a Controlling a Controlling a Project Stage Stage SB SB CP Delivering Managing Managing Product Product Delivery Delivery Copyright © AXELOS Limited 2017 PRINCE2® manual www.xpmconsulting.com 4

Overview of PRINCE2 Management Products  Baseline Management Products - Define aspects of the project and, once approved, are subject to Change Control, e.g. Benefits Management Approach  Records - Dynamic management products that maintain information regarding project progress, e.g. Risk Register  Reports - Management products that provide a snapshot of the status of certain aspects of the project, e.g. Highlight Report  Records and Reports are not subject to Change Control, but other aspects of Configuration Management still apply, e.g. version control, safe storage and access rights What Makes a PRINCE2 Project  Is applying PRINCE2's principles  Is meeting the minimum requirements set out in the PRINCE2 themes  Has project processes that satisfy the purpose and objectives of the PRINCE2 processes  Is either using PRINCE2's recommended techniques or using alternative, equivalent techniques Continued Business Justification  A requirement for a PRINCE2 project is that o There is a justifiable reason to start it o The justification remains valid throughout the life of the project o The justification is documented and approved Learn from Experience  “PRINCE2 project teams learn from previous experience; lessons are sought, recorded and acted upon throughout the life of the project.”  Lessons learned are considered o When starting a project o As the project progresses o As the project closes Defined Roles and Responsibilities  Projects must have explicit project management team structure  All projects have 3 primary stakeholders o Business sponsors o Users o Suppliers Manage by Stages  Planning is done at a manageable and foreseeable level, resulting in a sensible planning horizon through o Dividing the project into a number of management stages o Having a high level Project Plan and a detailed Stage Plan o Planning, delegating, monitoring and controlling the project on a stage by stage basis www.xpmconsulting.com 5

Overview of PRINCE2 Manage by Exception  Provides for efficient use of Senior Management time but retaining control  Delegated authority by setting tolerances against o Time, Cost, Quality, Scope, Risk, Benefit  Setting up controls for management if tolerances are forecast to be exceeded  Adding a layer of assurance Focus on Products  Focus is to fulfil the stakeholders’ expectations through the quality of its products  Output orientated not activity orientated  Product descriptions define each product’s purpose, composition, derivation, format, quality criteria and quality method  Avoids disputes and ‘scope creep’ Tailor to Suit the Project Environment  Universal project management method used regardless of project type, organization, geography or culture  Tailoring is used to o Align the method with the business culture and processes o Ensure that project controls are set appropriately within the context of the project environment Tailoring PRINCE2  Tailoring is mandatory  Processes may be combined or adapted  Themes can be applied using different techniques  Roles may be combined or split  Management products may be combined or split. May be formal documents, slide decks, wall charts,…  Terminology may be changed to suit other standards or policies  PRINCE2's principles should not be tailored www.xpmconsulting.com 6

Business Case Purpose of the Business Case Theme  “… is to establish mechanisms to judge whether the project is (and remains) desirable, viable and achievable as a means to support decision making in its (continued) investment.”  Is the project: o Desirable? o Viable? o Achievable?  Documents the business justification for the project What is a Business Case  Mix of information for investment decisions o Benefit o Cost o Risk o Contribution to strategic objectives  Provides confidence for Project Board and Stakeholders  Dynamic not static Responsibilities of the Business Case Theme  Project manager maintains the business case  Senior user specifies benefits  Executive is responsible for the whole business case and ensuring that benefits deliver value for money Outputs, Outcomes, (Dis-)Benefits Output A project produces specialist products (A new customer service IT system) Outcomes Which, when used, produce outcomes…(Quicker, more efficient customer call handling) Benefits Dis-benefits Which deliver measurable results perceived as positive or negative by stakeholders, which improves/increases organizational objectives 25% reduction in 5% increase in customer complaints infrastructure costs Business Case Contents (A.2)  Executive summary, reasons, business options (include ‘do nothing’), expected benefits, expected dis-benefits, timescale, costs, investment appraisal and major risks www.xpmconsulting.com 7

Business Case Business Case in the Project Lifecycle Confirm Confirm Confirm benefits benefits benefits Pre- Initiation Subsequent delivery stage(s) Final delivery stage Post-project project stage Verify outline Verify detailed Verify updated Business Case Business Case Business Case (Project Brief) (Project Initiation (Project Initiation Documentation) Documentation) Develop Maintain Business Case Business Case Pre-Project Initiation Subsequent Final Stage Stage Delivery Stages Corporate or ProgRreavmiewmtehMe baunsaingeesms ent case at the end of Directing DieraecchtipnhgaPseroject Starting Up Project Board a Project Controlling a Initiating a Controlling a Managing Project Stage Stage Project Manager SB SB CP Create the business case outline Create the detailed Managing Managing Delivering business case and Product Review busiPnreosdsuct case at pthroeDjeeecnltdivery Team Managienrclude it in the PID Delivery of the Benefits Management Approach (A.1)  Scope, covering what benefits are to be measured  Who is accountable for the expected benefits  How to measure achievement of expected benefits  What resources are needed  Baseline measures  How the performance of the project’s products will be reviewed Requirements for the Business Case Theme  Create and maintain a business justification (business case or equivalent)  Update the business justification in response to decisions and events  Define the management actions to ensure that outcomes are achieved and confirm that the benefits are realized (benefits management approach)  Define and document roles and responsibilities www.xpmconsulting.com 8

Organization Purpose of the Organization Theme  “… is to define and establish the project’s structure of accountability and responsibilities (the who?).”  A Project is a temporary organization with defined roles and responsibilities  Governance is through defining responsibility and accountability for directing, managing and delivery the project  Business, user and supplier representation is essential  Defined roles, NOT jobs Customer/Supplier Environment  Customer – specifies project result and (probably) funds the project  Supplier – provides resources and skills to produce desired products  In-house or commercial relationship  In a commercial relationship, there will be at least two sets of reasons for undertaking the project, management systems and governance structures and corporate cultures  A commercial relationship will affect the application of PRINCE2 Themes, Processes, Management Products Three Projects Interests  Consider the difference between “stakeholders” and “decision- makers” Four Levels of Management Corporate, programme management or customer Project management team Directing – Project Board Managing – Project Manager Delivering – Team Manager Project Management Structure Corporate, programme management or customer Senior User(s) Project Board Senior Supplier(s) Within the project management team Executive From the customer From the supplier Business, User and Project Manager Change Authority Lines of authority Supplier Project Team Manager(s) Project Support Project Assurance responsibility Assurance Lines of support/advice Team members 9 www.xpmconsulting.com

Organization The Project Board  Three roles: o Executive – business interests o Senior User – user interests o Senior Supplier – supplier interests  Authority and responsibility for the project within the remit of the Project Mandate and the Project Initiation Document once initiated  Characteristics: authority, credibility, ability to delegate and availability Project Board: Executive  Role: o Accountability for the project and its success or failure o Balances the demands of the business, user and supplier ensuring the project gives value for money throughout the life of the project  Responsibilities: o Organizes and Chairs Project Board Reviews o Owns the Business Case representing the “business” interests o Designs and appoints the project management team, particularly the Project Manager o Holds the Senior Supplier and Senior User to account o Focuses on continued business justification Project Board: Senior User  Role: o Represents the needs of all those who will use the project’s products o Accountable to the Business for the delivery of benefits beyond the life of the project  Responsibilities: o Ensures that requirements and quality expectations are fully specified and agreed before product delivery begins o Ensures that user resources are available o Resolves user requirement and priority conflicts o Monitors progress and maintains focus on the deliverables from a user perspective o Signs-off completed deliverables against agreed quality criteria Project Board: Senior Supplier  Role: o Represents the interests of those designing, developing or procuring and implementing the project’s products o Accountable for the quality of the product  Responsibilities: o Ensures that supplier resources are available o Resolves supplier requirement and priority conflicts o Provides cost information for the Business Case o Responsible for delivery of products to the quality level specified by the users o Advises on selection of design, development and acceptance methods www.xpmconsulting.com 10

Organization Project Assurance  Ensures the project is being run to the required quality standards to deliver the products, project controls are being executed and the Project Manager is performing effectively  Provides advice and guidance on project Management team member selection, risk management and monitoring of agreed tolerances  Assurance is the responsibility of all members of the Project Board  Cannot be delegated to the Project Manager  Should be involved in all processes User Project Board Supplier groups Executive groups Senior User Senior Supplier User Supplier representative representative (area 1) (area 1) User Supplier representative representative (area 2) (area 2) User Project Business Project Supplier Project Assurance Assurance Assurance Change Authority  The Project Board is responsible for the Change Control Approach and agreeing Requests for Change or Off-specifications  The Change Control Approach defines rating scales for severity of changes  Depending on severity, the request for change could be handled by corporate, programme management or customer, project Board, delegated to a Change Authority or delegated to the Project Manager  Any delegated authority must be agreed in role description Project Manager  Single focus for the day-to-day management of the project  Has authority to run the project on behalf of the Project board  Is responsible for The project delivering the required result on time and to budget, preparing the baseline management products and managing and motivating the project management team  Reports directly to the Project Board  Role should not be shared Team Manager  Ensures the products allocated by the Project Manager are produced to required quality level within constraints of time and cost  Plans and manages the work of a team through delivery of work packages www.xpmconsulting.com 11

Organization  Reports directly to the Project Manager - In a small project, the role could be combined with role of Project Manager  May be more senior in the organisation than the Project Manager but in the project team context takes direction from the Project Manager Project Support  The role of Project Support is not optional, but the use of a separate person to perform Project Support is o Depends on size and the complexity of the project o Can be covered by a separate Project Office if this exists  Key Competencies include administration and organization, knowledge of specialist tools and techniques, Knowledge of corporate or programme management standards applicable to the project Combining Roles  Executive and project manager roles cannot be combined  There can only be one executive and one project manager  Executive’s accountability cannot be delegated  Project assurance roles cannot be assigned to project manager, team manager or project support Working with Stakeholders  Stakeholder = Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (programme, project, activity, risk)  Communication Management Approach o A description of the means and frequency of communication between the project and its stakeholders o Documented during Initiating a Project o Incorporates Corporate communications facilities where appropriate Pre-Project Initiation Subsequent Final Stage Stage Delivery Executive and Stages Project Manager Project Management Team appointed Corporate or PraongdrCaommmmeunMicaantiaognement Management Approach Directing checkeDdiraencdtinupgdPartoedject Starting Up Project Board a Project Controlling a Initiating a Controlling a Managing Project Stage Stage ProjePctroject Manager SB SB CP Management Team designed Communication Managing CommunicMataionnaging Product ManagemPernotduct Deliverianngd appointed Management Delivery ApproacDhelivery Team Manager Approach checked created Requirements for the Organization Theme  Define all of the responsibilities in PRINCE2's role descriptions (Project Initiation document)  Define approach to communicating and engaging with stakeholders (Communication management approach) www.xpmconsulting.com 12

Starting up a Project Starting up a Project Process Purpose  “… to ensure that the prerequisites for Initiating a Project are in place by answering the question; do we have a viable and worthwhile project?” Starting up a Project Process Objectives and Context  Objectives o Ensure there is a business justification for initiating the project (business case outline) Non-viable projects are not continued to initiation o Establish the project management team structure (Project brief) o Analyze alternative ways to meet the business need and select the project approach (Project brief) o Build a foundation of project definition (scope, timescale, acceptance criteria and constraints ) to ensure that the project is not wasting time initiating projects (Project brief) and sufficient information is available o Plan the work of the initiation stage (Stage plan)  Triggered by Project Mandate Project Corporate or Directing a Mandate Programme Project Management AppoAinpt pthoeiEnxtectuhteive Executivaendand Project the ProMjeactnMaganearger Capture previous Design and appoint the lessons Project Management Prepare the outline Team Business Case Select the project Starting up a Project approach and assemble Request to initiate a project the Project Brief Plan the initiation stage Project Outline Project Management Team Business Case Product Description structure Project Project Definition Approach Issues and Risks? 13 www.xpmconsulting.com

Directing a Project Directing a Project Process Purpose  “… to enable the Project Board to be accountable for the project’s overall success by making key decisions and exercising overall control while delegating the day-to- day management of the project to the Project Manager.” Directing a Project Process Objectives  Ensure there is authority to initiate the project , deliver the products and close the project  Provide management direction throughout the project  Ensure that the project remains viable  Provide an interface to corporate, programme and customer level  Ensure that post-project benefits are managed Directing a Project Process Context  Starts on completion of Starting up a Project o Trigger is request to initiate a project  Covers the activities of the Project Board o Monitor project progress via reports o Event-driven decisions and no need for other ‘progress meetings’  Flow of information - Corporate, programme management or customer, project Manager Initiation Notification to Authorize Initiation Corporate or Programme Management Authorize Initiation • Is investment to initiate project worthwhile? • Review and approve Project Brief • Review and approve Initiation Stage Plan Request to initiate a project Authority to initiate Project Brief a project Initiation Stage Plan Starting up a Project Initiating a Project Authorize the Project Project Authorization Notification to Corporate or Programme Management Authorize the Project • Should we proceed with the rest of the project? • Is the project viable – Business Case? • Can the Project Plan deliver the Business Case? • Are mechanisms for measuring expected benefits in place? Initiating a Project Done in conjunction with www.xpmconsulting.com Authorize a Stage or Exception Plan for the first delivery stage 14

Directing a Project Authorize a Stage or Exception Plan Communicate Project Status or Exception Plan to Corporate or Programme Management Authorize a Stage or Exception Plan • Review project performance to date • Review Plan for which the PM is seeking approval • Is the project still viable, achievable, desirable? Request to approve next Stage/Exception or, Premature Stage/Exception Plan Plan Authorization Closure End Stage Report Controlling a Stage PID, Benefits Management Approach Managing a Stage Boundary Give Ad Hoc Direction Corporate advice and decisions Give Ad Hoc Direction • Respond to requests, reports and external influences • Raise concerns Project Manager request for advice Project Board advice Exception raised Exception Plan request Highlight Report, Premature close Exception Report, Issue Report New issue Initiating a Project, Controlling a Stage, Managing a Stage Boundary, Closing a Project Authorize Project Closure Closure Notification to Corporate or Programme Management Authorize Project Closure • Have the objectives been achieved? • How far did the project deviate from its original PID • Does the project have anything more to contribute? • Post-project benefits reviews planned? Closure recommendation Project closure notification inform End Project Report stakeholders that resources can be disbanded and PID, Benefits Management Approach support services demobilized. It should Draft Closure Notification indicate a closure date for costs to be charged Closing a Project www.xpmconsulting.com 15

Directin Initiation Project authorization re notification notification Authorize Authorize the project Initiation Authorize a Stage or Exception Plan Request to Authority to Request to Stage Request to initiate a initiate a deliver a authorization approve project project project Exception Plan Exception Plan approved Request to Starting up Initiating approve next a Project a Project Stage Plan Managi Stage Bou Con www.xpmconsu

ng a Project Project Board Corporate advice Closure equest for advice and decisions notification Directing a Project Give ad hoc direction Authorize project closure Exception Plan Request for New issue Premature Closure request advice close recommendati Project Board Exception advice and on raised decisions ing a Closing a undary Project ntrolling a Stage ulting.com 16

Initiating a Project Initiating a Project Process Purpose  “… to establish solid foundations for the project, enabling the organization to understand the work that needs to be done to deliver the project’s products before committing to significant spend.” Initiating a Project Process Objectives and Context  Ensure that there is a common understanding of: o Why the project should be done, expected benefits expected, risks o What will be delivered, how and when it will be delivered and at what cost o Who is to be involved in the project decision-making o How well it should be delivered o How the project will manage communication, risks, changes and progress  Triggered by Authority to Initiate a Project (Directing a Project process) Agree the tailoring requirements  Any deviation from the organization standard approach must be documented Authority to Agree the tailoring (Part of) Project initiate project requirements Initiation Documentation Project brief Project controls Lessons log Prepare the Risk Management Approach  Defines how risk management will be embedded in the project management activities: Procedures, tools and techniques, records and reports, roles and responsibilities, categories and scales, tolerances and risk budget  Create Risk Register - Record of identified risks relating to the project, information on all threats and opportunities, status and history, maintained by Project Support on Project Manager’s behalf, populated with risks from Daily Log Prepare the Change Control Approach  Defines the level of control to be exercised over the projects products - Change control procedures, tools and techniques, records and reports, Change Authority and change budget  Create Configuration Item Records o Record of configuration item information o Relationships  Create Issue Register Populate with issues from Daily Log  Maintained by Project Support on Project Manager’s behalf www.xpmconsulting.com 17

Initiating a Project Prepare the Quality Management Approach  Describes the project’s response to the customer’s quality expectations: Procedures for quality planning and control, quality assurance, tools and techniques, records and reports, roles and responsibilities  Create Quality Register o Summarizes all planned and actual quality management activities o Provide information for reports  Not populated just yet  Maintained by Project Support on Project Manager’s behalf Prepare the Communication Management Approach  Is the final approach to be produced  Facilitates stakeholder engagement  Defines both internal and external project communications activities: Communications procedures, tools and techniques, records and reports, timing, roles and responsibilities, stakeholder analysis, information needs for interested parties Setup the Project Controls  Project controls include o Communication between project management levels o Number and length of stages o Tolerances o Mechanisms for dealing with issues and exceptions  Done in conjunction with creating the Project Plan  Summarized in PID Create the Project Plan Review Project Review Lessons Review Daily Log Brief Log or Risk / Issue Registers Project Product Description Lessons from Project Approach previous projects? Related risks and issues? Create Project Plan • Create project plan (PID) • Update project management team structure (PID) • Create Product Descriptions (PID) • Update Configuration Item Records Seek Project New Risks or Board approval Issues? www.xpmconsulting.com 18

Initiating a Project Refine the Business Case Review Project Review Lessons Project Plan Review Risk Brief Log Register Outline Business Lessons from Time and Cost Major Project Case previous projects? Risks Refine the Business Case • Create (detailed) Business Case • Create Benefits Management Approach Consult Project Seek Project New Risks or Assurance Board approval Issues? Assemble the Project Initiation Documentation (PID) Inputs from Inputs from Initiating a Starting up a Project Project ‘What, why, who, Project Brief Strategies, Project Plan, how, where, when Business Case, Project Controls and how much? Consult Project Request to deliver Stage Boundary Assurance a Project Approaching www.xpmconsulting.com 19

Initiating a Authority to initiate projec Agree to tailoring requir Prepare the Prepare the Risk Management Approach Quality Manageme Approach Prepare the Communication Management Ap Set up the project controls Initiating a Project Refine the Business Case Assemble the Project Initiation Documentation Stage boundary approaching www.xpmconsu

a Project 86 o Request to ct deliver a project rements ent Prepare the Change Control Approach pproach Create the Project Plan ulting.com Managing a Stage Boundary 20

Quality Theme Purpose of the Quality Theme  “… is to define and implement the means by which the project will create and verify products that are fit for purpose.” Quality Audit Trail Quality Planning Quality Control Customer’s Quality Expectations Acceptance Products Quality Products Produced Criteria Checked Project Quality Quality Register Product Management Updated Description Approach Acceptance Criteria Product Quality Descriptions Register Sign Off Approach to Quality  Quality Planning o Understanding customer expectations and defining the project’s acceptance criteria o Methods and responsibilities for quality control and product acceptance in the Quality Management Approach  Quality Control o Checking to ensure that the finished product conforms quality criteria o Eliminating causes of unsatisfactory performance Project Product Description  Customers Quality Expectations - Statement about the quality expected from the project’s product  Acceptance Criteria o Criteria in the form of a prioritized list that the project product must meet before being accepted by the customer o Attributes acceptable to key stakeholders defined in a measurable way  Created in Starting up a Project, reviewed in Managing a Stage Boundary, and used by Closing a Project to hand over products  Subject to Change Control Quality Management Approach  Defining the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during a project  Created during Initiating a Project and specific to each project  Reviewed by Project Assurance  Should be aligned with the organization quality standards, procedures and responsibilities (quality management system) maintained by Quality Assurance www.xpmconsulting.com 21

Quality Theme Product Descriptions  Governs development, monitoring and approval of a product  Quality criteria o The quality specifications that a product must meet to be approved o The quality measurements that will be applied by those inspecting  Quality tolerances  Quality methods  Quality responsibilities Quality Register  Created in Initiating a Project and populated as plans are developed  Summarizes all planned and actual quality activities  Updated by Team Manager, but may be maintained by Project Support Quality Activity ID Product ID Product Quality Method Producer Reviewer(s) Approver(s) Target Review Date Actual Review Date Target Approval Date Actual Approval Date Result 1 121 Test Plan Inspection Ali Paulo John, Rita 14/2 21/2 21/2 28/2 Pass 2 124 Water Performance Test Paulo Ali, Bob John 20/3 20/3 27/3 Fail Pump Maintenance Test Paulo Ali, Bob Rita 21/3 21/3 27/3 27/3 Pass 3 124 Water Pump Quality Review Preparation Review Review Preparation Review Meeting Agenda Major Minor Defects Defects Corrective Review Action Follow-up Approved Configuration Library Quality Assurance vs. Project Assurance  Quality Assurance - An independent (of the project team) check that ensures products will be fit for purpose or meet requirements; reports to the wider organization; external to the project  Project Assurance - Provides the Project Board with assurance that the project is being run appropriately; Independent of the Project Manager but not of the project; reports to the Project Board; Internal to the project Requirements for the quality theme  Define quality management approach www.xpmconsulting.com 22

Quality Theme  Specify explicit quality criteria for products (product descriptions)  Maintain records to provide evidence of quality activities (quality register)  Specify the customer's quality expectations and acceptance criteria (project product description) www.xpmconsulting.com 23

Plan Theme Purpose of the Plan Theme  “… is to facilitate communication and control by defining the means of delivering the products (the where and how, by whom, and estimating the when and how much).” What is a Plan  A detailed proposal for doing or achieving something which specifies the what, when, how and by whom it will be achieved. • Longest timescale, least detail Project Plan Levels of Planning • Determined by the Project Plan Stages  PRINCE2 recommends 3 levels of plan to Stage Plan reflect the different levels of management involved in the project, • Shortest timescale, most detail stage and team Team Plan  PRINCE2 recommends 3 levels of plan to reflect the different levels of management involved in the project, stage and team Corporate or programme plan Project Plan (Initiation) Stage (Delivery) Exception Plans Plan Stage Plans as necessary Team Plans The Project Plan  Provides a statement of how and when a project’s time, cost, scope and quality targets are to be achieved  Shows major products, activities and resources  Provides the Business Case with project costs  Is used by the Project Board to monitor and control project costs and progress  Identifies major project control points (e.g. stages)  Should be in line with corporate/programme plans The Stage Plan  For each Stage identified, a Stage Plan is required  Each element within the Project Plan will be broken down to a level of detail to enable adequate day-to-day control by the Project Manager  Identifies the method of quality checking products and activities involved  Each Stage Plan is completed near to the end of the preceding stage o Gives greater confidence in the plan o Assistance from Team Managers/members www.xpmconsulting.com 24

Plan Theme The Team Plan  An optional plan  Need and number determined by size and complexity of project  Contains detailed information to assist in the management of Work Packages  Detailed activity and resource requirements for quality control  May be prepared in parallel with Stage Plan  Could be owned by Third party suppliers on certain projects – the Project Manager may not have control over Team Plans The Exception Plan  Prepared for the appropriate management level to show the actions required to recover from the effect of a tolerance deviation  Same level of detail and format  Picks up from current plan actuals  Continues to the end of the plan  Will become the new baselined Project Plan or current Stage Plan  Exception Plan for Project Plan – approved by Corporate or Programme Management  Exception Plan for Stage Plan – approved by Project Board Plan Contents (A.16)  Project/Stage/Exception Plan description, plan pre-requisites, external dependencies, planning assumptions, lessons incorporated, monitoring and control, budgets, tolerances, product descriptions and schedule Plan in the Project Lifecycle Pre-Project Initiation Subsequent Final Stage Stage Delivery Stages Directing Directing Project Project Managing Plan Starting Up a Project Stage Plans Initiating a Controlling a Controlling a Project Stage Stage Team Plans SB SB CP Delivering Managing Managing Product Product Delivery Delivery www.xpmconsulting.com 25

Plan Theme Approach to Planning Focus on Designing the plan Prerequisite Products Analysing risk to a plan Defining and analyzing the products Use product- Identifying activities and dependencies based planning Preparing estimates technique Preparing a schedule Repeated for: • Project Plan • Stage Plan • Team Plan (optional) Documenting a plan Product-Based Planning Writing the Project Product Description For Project Plan only Defines what the project must deliver Creating the product breakdown structure Major Products Identified Writing the Product Descriptions For all levels of plan For all Creating the product flow diagram identified products Defines the sequence of development Requirements for the Plan Theme  A description of the overall project's output (Project product description)  A description of each product's purpose, composition, derivation and quality criteria (Product description)  Hierarchy of all the products to be produced during a plan (Product breakdown structure)  Produce a project plan for the project as a whole and a stage plan for each management stage  Produce specific exception plans for managing exceptions www.xpmconsulting.com 26

Risk Theme What is a Risk Cause Expert did not validate Event assumptions  An uncertain event or set of events that, Effect Equipment may not have the should it occur, will have an effect on the necessary throughput achievement of objectives Increase on project costs  Consists of probability that it will occur, and schedule delay impact on objectives and also consider its Proximity  May be negative (threat) or positive (opportunity) Overall Risk Exposure  The extent of risk borne by the organization at the time Purpose of the Risk Theme  “… is to identify, assess and control uncertainty and, as a result, improve the ability of the project to succeed.”  Identify  Assess Implement Identify  Control Risk Management Procedure Communicate Plan Assess Identify: Risk Management Approach  Risk Management Procedure (Identify, Assess, Plan, Implement and Communicate), tools and techniques, records, reporting, timings of activities, roles and responsibilities, scales, proximity, risk categories, risk response categories, early warning indicators, risk tolerance, risk budget Identify: Recording Risks  Risk Register o Records risks and their management o Format defined in the risk management approach o Input to Business Case o Could be maintained by Project Support/input to by Team Managers Assess  Estimate individual risk o Assess probability, impact of individual risks o Proximity (how quickly it might happen) o How it may change over the life of the projects o Techniques such as Expected Value, Probability and Impact Grid, Heat Map  Evaluate overall project risk o Net effects of aggregated threats and opportunities o Within tolerance? Continued business justification www.xpmconsulting.com 27

Risk Theme Plan – Risk Responses Categories Threat responses Opportunity responses Avoid Exploit (Remove the uncertainty) (Remove the uncertainty) Reduce Enhance (Reducing the probability and/or (Increasing the probability and(or impact) impact) Transfer (Allocates part of the threat or opportunity to a third party) Share (Share the risk on a gain/pain basis) Accept (No action is taken and organization takes the change)  Contingent plan - Conditional plan activated if a specific condition occurs Implement  Action the selected Response(s): o Monitor Implementation o Take any corrective action o Review roles and responsibilities  Risk Owner - Responsible for the management, monitoring and control of all aspects of a particular risk assigned to them, including the implementation of the selected responses  Risk Actionee - Assigned to carry out risk response action(s) to respond to a particular risk or set of risks. They support and take direction from the Risk Owner Communicate  Communicate risks using PRINCE2 management products: Checkpoint reports, highlight reports, end stage reports, end project report, exception reports  Other methods: Dashboards, Information radiators, … Requirements for the risk theme  Create and maintain a description of how risks will be managed, including processes, procedures, techniques, standards and responsibilities (risk management approach)  Record of identified risks (risk register)  Ensure that risks are identified, assessed, managed and reviewed www.xpmconsulting.com 28

Progress Theme Purpose of the Progress Theme  “… is to establish mechanisms to monitor and compare actual achievements against those planned; provide a forecast for the project objectives and the project’s continued viability; and control any unacceptable deviations.” Progress Controls  Enable each level in the project management team to: o Monitor progress o Compare level of achievement with plan o Review plans and options against future situations o Detect problems and identify risks o Initiate corrective action o Authorize further work  Event-driven controls - Take place when a specific event occurs, e.g. end of a stage, end of financial year,..  Time-driven controls - Take place a pre-defined periodic intervals, e.g. monthly Highlight Report Project Board and Project Manager Controls Pre-Project upPdaraontIjednesSicHttt–iiaagBEgthonieloadigrndhSt:taRpgereopRgoerretpssosrStsuDbSestlaeivgqeeurseynt Final Stage Project Board Project Board: exceptions Authorizations and changes – Exception Corporate or Programme Management Reports and Issue Reports Directing Directing Project Managing Starting Up a Project SB SB CP Initiating a Controlling a Controlling a Project Stage Stage Delivering Project Manager: Managing Managing authorizations Product Project ManaDgeelri:veprryogress Product updates – Checkpoint Reports DeliPvreorjyect Manager: exceptions and changes Delivery Steps Specifying Sprint 1 Sprint 2 Designing Building Training Sprint 3 Sprint 4 Commissioning Commissioned Facility Delivery steps = Phases within an waterfall approach (specifying, designing,…) Delivery steps = Sprints within an agile approach (Sprint 1, sprint 2,…) www.xpmconsulting.com 29

Progress Theme Management Stages - Delivery steps aligned with management steps M anagem ent stage 1 M anagem ent stage 2 M anagem ent stage 3 M anagem ent stage 4 Specification Detailed Peripheral design design Overall design Training Built facility syllabus Trained staff Commissioned facility Management stage = commitment of resources and authority to spend Management Stages - Delivery steps crossing management steps M anagem ent stage 1 M anagem ent stage 2 M anagem ent stage 3 M anagem ent stage 4 Specification Design Built facility Training Commissioned facility Management stage = commitment of resources and authority to spend How to Define Stages Alignment with the Programme benefit Balance too many short delivery tranches? stages vs. too few long ones Planning horizons – how far ahead can we plan? Number of Length of stages? stages? How much risk is involved? Key decision Where do delivery steps end? points? Confidence in plans? www.xpmconsulting.com 30

Progress Theme Tolerances Exception point Tolerance (+) Forecast Target Controlled Delegation Tolerance (-) Corporate, programme management or customer Project tolerances Project progress/exceptions Project Board Stage progress/exceptions Stage tolerances Project Manager Work Package tolerances Work Package progress/issues Team Manager Tolerances: Areas and Levels Tolerance Project Level Stage Level Work Package Product Level Area Level Project Plan Stage Plan Product Time Project Plan Stage Plan Work Package Description Cost Project Plan Stage Plan Work Package Scope Project Product Work Package Quality Description Risk Management Risk Approach Business Case Benefits Reviewing Progress  Daily Log (A.7) - Project Manager’s project diary; Tool to record actions.  Lessons log (A.14) - Project repository of all lessons generated in other projects that apply for this projec… or lessons that were generated in the project  Work package (A.26) - Information about or more products used to establish an agreement between the project manager and the team manager Reporting Progress  Checkpoint Report (A.4) o Time-driven report from Team Manager to Project Manager o Frequency defined in Work Package  Highlight Report (A.11) o Time-driven report from Project Manager to Project Board o Summary of management stage and project progress o Advise the board of problems that require help o Frequency defined in Communication Management Approach  Exception Report (A.10) o Used when a stage plan or project plan is forecasted to exceed tolerances o Inform the board and recommend remedial actions www.xpmconsulting.com 31

Progress Theme  Lessons Report (A.15) - Pass on relevant lessons to other projects  End Stage Report (A.9) o Produced in Managing a Stage Boundary o Summary of progress at the end of the stage o Used along with the next stage plan to authorize the next stage, review scope or terminate the project  End Project Report (A.8) o Produced in Closing a Project o Reviewed how the project performed against the PID o Lessons useful to other projects o Relevant details for the future (unfinished work, risks,…) Requirements for the progress theme  Define approach to controlling progress  Managed by stages  Set tolerances and be managed by exception against these tolerances  Review the business justification when exceptions are raised  Raise lessons www.xpmconsulting.com 32

Controlling a Stage Controlling a Stage – Purpose  “… to assign work to be done, monitor such work, deal with issues, report progress to the Project Board, and take corrective actions to ensure that the stage remains within tolerance.” Controlling a Stage – Objectives and Context  Objectives o Ensure that the project remains focused on delivering the stage’s products o Ensure that products are delivered within quality standards and costs and schedule constraints o Ensure that risks and issues are managed o Ensure that any impact on the business case is reviewed o Report progress to the Project Board, and take corrective actions to ensure that the stage remains within tolerance  Triggered by stage authorization or Exception Plan approval by the Project Board Work Packages Authorize Work Managing Product Delivery Packages  Agreement of Work Package with team manager  Receive Checkpoint Report and update registers and Review Work Package Status stage plan to reflect progress Receive completed  Confirmation of specialist product approvals Work Packages Problem Handling Capture and examine issues  Capture events that require managing  Handle formal issues with Issue Report and risks  Forecast any tolerance threats and raise Exception Review the Reports stage status  Assessment and recommendation of corrective actions Escalate issues Take corrective and risks action Give ad hoc direction Monitoring and Reporting Review Work Package status  Use the work package status to update the Stage Plan status  Progress reporting to Project Board and other stakeholders Review the stage status through Highlight Report Report highlights  Triggers for the next stage and closing the project www.xpmconsulting.com Give ad hoc direction 33

Controllin Risks and Issues Controlling Escalate Issues and a Stage Risks Take corrective action Rev Work Authorize Work Review Packages Packages Managing Authority to deliver work packages www.xpmconsu

ng a Stage Monitor and Report Report highlights view the stage status Capture and examine New Issue issues and risks w Work Package Receive completed status Work Package Complete Work Package Product Delivery ulting.com 34

Managing Product Delivery Managing Product Delivery Process Purpose  “… to control the link between the Project Manager and the Team Manager(s), by placing formal requirements on accepting, executing and delivering project work.” Managing Product Delivery Process Objectives and Context  Objectives o Ensure that the team work is authorized and agreed o Ensure that there is a common understanding among project manager, team managers and team members of scope, schedule, cost and quality o Ensure that products are delivered to expectations and within tolerance o Provide accurate progress information to the project manager at an agreed frequency  Triggered by authority to deliver a Work Package from Project Manager (Controlling a Stage) Process Overview Controlling a Stage Authority to Complete deliver Work Package Work Package Accept a Execute a Deliver a Work Package Work Package Work Package Managing Product Delivery Accept a Work Package (A.26) Controlling a Stage Authorize a Work Package Authority to deliver a Work Package Accept a Work Package Managing Product Delivery Team Plan created New risks raised Quality Register updated Work Package approved www.xpmconsulting.com 35

Managing Product Delivery Execute a Work Package (A.26) Controlling a Stage Review Work Package status Checkpoint Report Quality Register Execute a Work Package Managing Product Delivery Specialist products created New risks raised Team Plan and CIRs updated New issues raised Deliver a Work Package (A.26) Controlling a Stage Receive completed Work Package Complete Work Package Deliver a Work Package Managing Product Delivery Work Package updated Team Plan updated www.xpmconsulting.com 36

Managing a Stage Boundary Managing a Stage Boundary Process Purpose  “… to enable the Project Board to be provided with sufficient information by the Project Manager so that it can review the success of the current stage, approve the next Stage Plan, review the updated Project Plan, and confirm continued business justification and acceptability of the risks.” Managing a Stage Boundary Process Objectives  For managing a stage boundary: o Assure the board that products in the stage plan have been completed and approved o Prepare the stage plan for the next management stage o Review and, if necessary, update the PID o Provide the information needed for the board to assess the project continuing viability o Record lessons that can help later management stages o Request authorization to start the next management stage.  For managing exceptions: o Prepare an exception plan as directed by the project board o Seek approval to replace the project plan or stage plan for the current management stage with the exception plan. o Provide the information needed for the board to assess the project continuing viability o Review and, if necessary, update the PID Managing a Stage Boundary Process Context  Triggered by: o Stage boundary approaching (routine) o Exception Plan request (from Project Board)  Routine stage end o Plan the next stage (update PID and registers and create next Stage Plan), update the Project Plan (actuals and forecast); update the Business Case (Benefits Management Approach), Report Stage End  Exceptions o Produce Exception Plan (Update PID and registers and create Exception Plan) o Request approval to replace Project or Stage Plan with Exception Plan Plan the Next Stage or Produce an Exception Plan Acceptance Criteria? Any updates Strategies or controls? required to PID? Project Management Team? Stage Plan or Exception Plan Update Create/Update Update Update Risk Quality Configuration Issue Register Register Item Records Register www.xpmconsulting.com 37

Managing a Stage Boundary Update the Project Plan Update Issue Current Register Stage Plan New/changed Next Stage Actuals Update issues/risks Plan or Project Forecasts Update Exception Plan Risk Plan New/changed requirements Register PID Update the Business Case Risk Update Update Register Business Issue Register Project Case Risk Profile New/changed Update issues/risks Issue Changes Benefits Register Management Update Approach Risk Time/costs Register Project Plan Report Stage End Yes End Stage Report  Current Business Case status and benefits Request to approve achieved? next Stage Plan/ Exception Plan  Stage objectives met?  Plans still achievable? Directing a Project  Team performance reviewed?  Product Status Account reviewed for product performance?  Quality activity results reported?  Issues and risks updated?  Lessons Report required www.xpmconsulting.com 38

Request to approve Managing a S Exception Plan Direct Request to approve next Stage Plan B Report stage end Managing a Stage Pla Boundary S Initiating a Project www.xpmconsu

Stage Boundary Exception Plan request ting a Project Produce an Exception Update the Plan Business Case Controlling a Stage Update the Project Plan 39 an the next stage Stage boundary approaching ulting.com

Change Theme Purpose of the Change Theme  Identify, assess and control any issue which has a potential impact on baselines.  Impact may be on plans or completed products  Includes managing issues such as problems and concerns Issues  An Issue is “ …any relevant event that has happened, was not planned, and requires management action”  Can be about anything related to the project  Anyone with an interest in the project and/or its outcome can raise an issue at any time  Three types of issue: Request for Change (RFC); Off-specification; Problem, query and suggestion Issue Type Definition Considerations Request for Change Proposal for a change to a • Tolerance should NOT be used baseline • Use Change Budget? Off-specification • Increase project budget? Problem • De-scope other elements? Something that should be • Grant a concession? provided by the project, but • Request Exception Plan? currently is not Any other issue or concern • Relax stage tolerances? • Request Exception Plan? Establishing Controls for Change - Define a Change Control Approach  Introduction, configuration management procedure, issue and change control procedure, tools and techniques (e.g. decide if there is a change budget), records, reporting, timing of configuration management activities and change control activities, roles and responsibilities (e.g. establish change authority), scales for priority and severity Manage by Exception Project Board/Change Authority Request for advice Request for advice/ Exception Report Capture Assess Propose Decide Implement • Determine • Assess impact • Identify • Escalate if • Take issue type on project options beyond corrective objectives/ delegated action • Determine Business Case • Evaluate authority severity/ and project risk options • Update priority profile • Approve, reject records and • Recommend or defer plans • Log/ • Check severity/ options recommended Register priority option Daily Log or 40 Issue Register/Issue Report www.xpmconsulting.com

Change Theme Establishing Controls for Change - Change Records and reports  Issue log - Record issues informally  Issue register - Capture and maintain information on all the issues that are being formally managed.  Issue report - Report containing the description, impact assessment and recommendations for those issues that need to be handled formally. Issue and Change Control in the Project Lifecycle Issue Register reviewed Pre-Project Initiation Subsequent Final Stage Stage Delivery Stages Issue Register closed Directing Directing Project Managing Starting Up a Project SB SB CP Initiating a Controlling a Controlling a Project Stage Stage Change Control Approach Managing Managing Product Product Deliverinangd Issue Register created Delivery Delivery New issues logged in Issue Register Managing product baselines - What is Configuration Management?  “ …the technical and administrative activity concerned with the change of a product.”  Configuration Item = an entity subject to change control o Component of a product o Product o Set of products in a release  Enables impact assessment by holding information about relationships  Maintains baselines – a defined state Managing product baselines - Configuration Management Activities  Defining the level of configuration required and how to achieve this  Establishing a unique identification of each product and version  Ensuring that nothing moves or changes without authorization  Maintaining records of configuration items  Reporting on current and historical data  Checking actual product state against records held Managing product baselines - Configuration management records and reports  Configuration item records 41 www.xpmconsulting.com

Change Theme o Created only if required by the project's change control approach. o Record of the history, status, version and variant of each configuration item.  Product status account - Provide information about the state of products within defined limits. It is particularly useful to confirm the version number of products. Managing product baselines - Configuration management records and reports  Configuration item records o Created only if required by the project's change control approach. o Record of the history, status, version and variant of each configuration item.  Product status account o Provide information about the state of products within defined limits. It is particularly useful to confirm the version number of products. Requirements for the change theme  Define how issues are identified and managed …  … and how product baselines are created, maintained and controlled (change control approach)  Maintain an updated record of project issues, including information about analysis, management and review (issue register) www.xpmconsulting.com 42

Closing a Project Process Closing a Project - Purpose  “… to provide a fixed point at which acceptance for the project product is confirmed, and to recognize that objectives set out in the original Project Initiation Documentation have been achieved (or approved changes to the objectives have been achieved), or that the project has nothing more to contribute.” Closing a Project - Objectives and Context  Verify user acceptance of the project's products  Ensure that the host site is able to support the products  Review the project performance against its baselines  Assess any benefits that have already been realized  Prepare follow-on action recommendations to address all open issues and risks Directing a Project Controlling a Project end Prepare planned Premature Close Stage approaching closure Prepare premature closure Hand over products Evaluate the product Closing a Recommend Closure Project product closure Recommendation  Triggered by project end approaching (routine) and premature closure (from Project Board) Prepare Planned or Premature Closure Project Product Project Plan Issue Product Status Register Description Account Acceptance Confirm state of Updated with final Update with premature Criteria met? products stage actuals closure request PlPaPrnelanmneaPPnCdtreruleooedrprspeaCuPaCrrrlreeoeelosmsuuarertuere Consult Project Seek approval to Additional work Assurance release resources estimates www.xpmconsulting.com 43

Closing a Project Process Hand Over Products Change Control Support environment in place? Approach Early life-support? How are products to be Service agreement/contract? handed over and to whom? Follow-on Action Transfer of Recommendations ownership Post-project reviews? Update Configuration Item Records End Project Benefits Acceptance Report Management Plan Records Evaluate the Project Issue, Risk, Quality Lessons Log Registers Original and current PID Project data What went well? In what ways could it have been better? Evaluate the Project • Review of project and team performance against targets • Assessment of results vs. expected benefits • Review lessons, measurements and success of tailoring Recommend Project Closure  Close all project Registers and Logs  Archive project information for future audit  Draft closure notification o Project infrastructure and resources can be withdrawn o Closing date for costs to be charged to project o Reviewed by Project Board.  Notify stakeholders of project closure o As per Communications Management Approach www.xpmconsulting.com 44