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