Business Case ESSENTIALS PROJECT MANAGEMENT FUNDAMENTALS. PMO South Africa (Pty) Ltd 2012/189587/07

Transcription

1 Business Case ESSENTIALS PROJECT MANAGEMENT FUNDAMENTALS

2 Business Case Essentials 1. What is a Business Case? 2. The PRINCE2 approach to the Business Case. 3. Business Case content. 4. Essential elements. 5. Credibility, practical value and accuracy. 6. Costs and benefits. 7. Making assumptions. 8. Estimating costs. 9. Estimating benefits. 10. Financial value for non-financial objectives. 11. Calculating return on investment and other financial metrics. 12. Sensitivity analysis. 13. Risk analysis. 14. Practical. <#>

3 Project Management Fundamentals 1. What is a project? 2. What is Project Management? 3. The project lifecycle. 4. Time, cost, quality, scope, benefit, risk. 5. Stages & phases. 6. Initiating, delivering, closing. 7. Monitoring & reporting progress. 8. Project Management & the Business Case. <#>

4 Strategy What is strategy: It is a high level plan to achieve one or more goals under conditions of uncertainty. It becomes ever necessary when it is known or suspected that there are insufficient resources to achieve these goals. It is also about attaining and maintaining a position of advantage over adversaries through the successive exploitation of known or emergent possibilities rather than committing to any specific fixed plan designed at the outset. What is agile strategy: Chess. Why strategy? Strategy process: Vision, mission, objectives, goals, deliverables, projects, tasks, sub-tasks. Delivering on strategy: Sub-tasks, tasks, projects, deliverables, goals, objectives, mission, vision. Where does the Business Case fit in? What happens if market conditions and/or strategy changes? What happens to the Business Case or project? <#>

5 Portfolio and Programme Management Project Portfolio Management: is the centralised management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyse and collectively manage a group of current or proposed projects based on keyc haracteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organisation s operational and financial goals while honouring constraints imposed by customers, strategic objectives or external real-world factors. Programme Management: is the process of managing several related projects, often with the intention of improving an organisation's performance. In practice and in its aims it is often closely related to systems engineering and industrial engineering. Why Portfolio Management? Why Programme Management? Where does the Business Case fit in? What happens if a portfolio/programme is not being successful? <#>

6 Programme Environment Programme will define standards to be used when developing the Business Case. Project Business Case will be aggregated into Programme Business Case. Likely to be reduced in content: Details of budget. List of benefits and tolerance. State how the project is contributing to the programme. Could be produced and maintained by the programme. Could exist before the project is initiated. Benefits will be defined, tracked and managed by the programme. Benefits Review Plan will be part of the programmes Benefits Realisation Plan. <#>

7 Project Sponsor What is a project sponsor? Why a project sponsor? Who represents your business case for approval? Who is accountable for the business benefits/success or failure of the business or project. Who is responsible for the project: Time. Cost. Scope: Specification, Quality and Risk. Business benefits/roi. CSF s (Critical Success Factors). What is the difference between: A projects time, cost and scope. Business case benefits measurement (Roles). When does business measurement occur? <#>

8 PMO (Project Management Office) What is a PMO? Why a PMO? What does a PMO do? Business case scorecard. Resourcing. Business case quality approval. Business case monitoring. Project approval. Project monitoring. Project closure. Projects/business case benefits measurement and control. <#>

9 Balanced Scorecard Programme Management <#>

10 Balanced Scorecard Programme Management <#>

11 Balanced Scorecard Programme Management <#>

12 Project Life Cycle

13 What is a Business Case? What is a Business Case? Examples of a Business Case. What is a good Business Case? What is a bad Business Case? Basic requirements questions: Can you approve? Can you deliver it? Can you control? Can you measure its success? Business Cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief. <#>

14 Why Do Business Cases Vary? Does size, complexity or risk make a difference to a Business Case? Does the experience, knowledge and qualifications of those approving make a difference to a Business Case? Good or bad either way? <#>

15 What is a Business Case? The justification for an organisational activity (project) which typically contains costs, benefits, risks and timescales and against which continuing viability is tested. A business case defines the delivery of one or more business products by the project/temporary organisation that was created for that very purpose. PRINCE2 ensures that participants focus on the viability of the project in relation to its business case objectives rather than simply seeing the completion of the project as an end in itself. The business case gets the planned project costs and timescales, and identifies the major control points, such as management stages and milestone from the project plan. Control of progress ensures that the project remains viable against its approved business case. Ensure that the project remains focussed on the corporate or programme objectives set, and remains justified in accordance with its business case as response to the receipt of a highlight report. PRINCE2 recommends determining the options for recovery and assessing them against the business case when escalating issues and risks. The business case needs to reflect the changes in the project s external environment as well as the nature and timing of the project s products because projects must have continued business justification (i.e. the project board is ordinarily only authorised to continue while the project remains viable). <#>

16 What is a Business Case? Continued The Executive is responsible for updating the business case. How to update the business case: Check whether risk tolerances need to be redefined. Update the benefits review plan with the results from any benefits reviews undertaken during the stage. Examine and review: Benefits review plan. Impact of approved changes. Project risk file and key risks. Issue register. Project plan to see whether the final implementation date of the project has changed. Project plan to see whether the cost of delivering the project s products has changed. The corporate/programme environment into which the project s products will be delivered. Whether any benefits reviews are required. Revise the business case. Update the risk and issue registers as necessary. <#>

17 What is a Business Case? Continued A project may not start with a pre-defined business case because the specification is driven by the business case. PRINCE2 handles the evolving paradigm as the business case represents a best and agreed forecast at a particular point in a project s lifecycle which will evolve as the project moves from discovery to implementation. The outline business case: Developed pre-project. Has wide-range forecast of desired outcomes. Detailed business case: Updated mid-project. Has a narrower forecast. As the project progresses the set of products, required to provide the desired outcomes, also evolve. <#>

18 What is a Business Case? Continued Evolving business case value: Enables organisation to make an investment commitment that is commensurate with the expected benefits and risks forecast at the time in the project s evolution. Provides the basis for the control and impact assessment of requested changes as a result of the contestable and open to negotiation throughout the project s life aspects of modern projects. <#>

19 What is a Business Case? Continued Presents the optimum mix of information used to judge whether the project is and remains desirable, viable and achievable and therefore worthwhile investing in. In PRINCE2 the business case provides the vital test of the viability of the project (is the investment in this project still worthwhile). It is not static because the viability question is on-going, should be actively maintained throughout the life of the project, it should be continually updated with current information on costs, risks and benefits. Types of business case is determined by the type of project (compulsory, not for profit, evolving, customer/supplier, multi-organisation) because this will determine the type of measure being used (i.e. return on investment or other non-financial benefits). At various stages in the project, the business case should be reviewed to ensure that: The justification is still valid. The project will deliver the solution to the business need. The result of a review may be the termination or amendment of the project. The business case may also be subject to amendment if the review concludes that the business need has abated or changed, this will have a knock on effect on the project. <#>

20 Reasons for creating a business case Business cases are created to help decision-makers ensure that: The proposed initiative will have value and relative priority compared to alternative initiatives. The firm has the capability to deliver the benefits. The firm s dedicated resources are working on the highest value opportunities. Projects with inter-dependencies are undertaken in the optimum sequence. The performance of initiatives is monitored objectively based on the objectives and expected benefits laid out in the business case. The business case must demonstrate that: The issues have been thought through. The full benefits will be realized on time. Any technical aspects have been thoroughly evaluated. Cost and track and measure their achievement. <#>

21 What is R.A.C.I.? Who is: Responsible. Accountable. Consulted. Informed. Why is R.A.C.I. so important? <#>

22 Corporate/Programme Executive Senior Supplier Project Manager Project Manager Project Assurance Project Support Product Description available Who Is Responsible For Preparing The Outline Business Case? Producer Responsible for product s production Reviewer Ideally independent of production Approver Confirms approval Product Action Outline Business Case Create A P R R R R A2 Project Product Description Create (A) (A) (A) P R A2 1 Daily Log Update P A7 22

23 Why a Business Case Budgeting/strategy. Approval. Control. Measurement. Market demand. Organisational need. Customer request. Technological advance. Legal requirement. Ecological impacts. Social need. Problem. <#>

24 Types of Business Case Profit project: ROI/break even. Compulsory project: Government legislation. Not-for-profit project (balanced scorecard): 1. Financial. 2. Customer. 3. Internal business processes. 4. Learning. Evolving project. Customer/supplier project. Multi-organisation project. Investment project. Non-core project. <#>

25 Business Case Trigger Points Vision Mission Objectives Goals Deliverables Projects Tasks Subtasks. Capital Projection and Budgets. Project Plan. Technical Specification. Measurement of success of a project: Time, cost, scope, quality, risks, benefits. Outputs. Customer satisfaction. User satisfaction. Business benefits. Return on investment (ROI) or business reason. Business case. Measurement of success of business: Projects. Business case. Portfolio and/or programme. Capital budgets. Strategy. <#>

26 Essential Elements of the Business Case The components of a business case may change depending on the template or methodology used, but the essential elements will remain the same: Executive Summary: Enables decision makers to very quickly understand the essence of the business case. It should include all main points made in the business case. Including all the recommendations. Should be a stand-alone part of the document. The detail is located in the business case itself. An effective executive summary will capture the interest of the decision maker. They will want to know more and be quickly interested in the project or initiative. It should be used to sell the project or initiative to the person reading it. This section is placed at the beginning of your business case. Should be the last section to be written. Ensure that you have a very clear understanding of what is included in your business case when you summarise it. <#>

27 Essential Elements of the Business Case Continued Objectives & Scope: Provides direction at the beginning of the document about what the project will achieve if the business case is supported. Should be brief, concise and set the scene for the business case. Objectives should be phrased in terms of how supporting the business case will improve an aspect of agency business or assist the agency to meet its strategic objectives. Options. Cost-benefit analysis. Risk assessment. Recommendation. <#>

28 Business Case Size Experience. Standards. History. Complexity. Time. Cost. Scope: Specification. Quality. Risks. <#>

29 Business Case Content Summary: What, when, why, duration, time, cost, risk, specification, quality. What? Why? ROI (Return on investment). CSF s (Critical success factors). Strategy. Portfolio. Programme. Duration: Start. End. Time: Man Hours. Cost. <#>

30 Business Case Content Continued Scope: Specification. Quality. Standards. Governance. Risks. Motivation or Summary Description. Business Description. Technical Description. Project Sponsor. RACI: Who is Responsible. Who is Accountable. Who to Communicate to. Who to Inform. Customer. Project Sponsor. Signatories on Specification. Signatories on Project Close. <#>

31 Business Case Content Continued Objectives & Scope: Provides direction at the beginning of the document about what the project will achieve if the business case is supported. Should be brief, concise and set the scene for the business case. Objectives should be phrased in terms of how supporting the business case will improve an aspect of agency business or assist the agency to meet its strategic objectives. Options. Cost-benefit analysis Risk assessment. Recommendation. Priority. Options: A why? B why? C why? <#>

32 Business Case Content Continued Business Case Quality. Requires further detail or motivation. Department. Division. Area. Business Benefits. Business Dis-benefits. Benefit measurement, over what time. Constraints: Schedule. Resources. Budget. Staffing. Technical. Other. <#>

33 Business Case Content Continued Phases/Stages. High level project plan. Accuracy of business case. Proof. Attachments. History. What will happen if we do not do it? Reference: Origins. Background. Current state. Context: Opportunities. Quotes. Photos. <#>

34 Business Case Scorecard / Checklist Headings Headings Summary: (what, when, why, duration, time, cost, risk, specification, quality) Scope: Specification. What. Quality. Why. Standards. ROI (Return on investment). Governance. CSF s (Critical success factors). Risks. Strategy. Motivation or Summary Description. Portfolio. Business Description. Programme. Technical Description. Duration: Project Sponsor. Start. RACI: End. Who is Responsible. Time: Who is Accountable. Man Hours. Who to Communicate to. Cost. Who to Inform. <#>

35 Business Case Scorecard / Checklist Continued Headings Objectives & Scope: Options. Provides direction at the beginning of the document about what the project will achieve if the business case is supported. Should be brief, concise and set the scene for the business case. Objectives should be phrased in terms of how supporting the business case will improve an aspect of agency business or assist the agency to meet its strategic objectives. Cost-benefit analysis. Risk assessment. Recommendation. Priority. Options: Why A? Why B? Why C? <#>

36 Business Case Scorecard / Checklist Continued Headings Headings Business case quality. Phases/stages. Requires further detail or motivation. High level project plan. Department. Accuracy of business case. Division. Proof. Area. Attachments. Business benefits. History. Business dis-benefits. What will happen if we do not do it? Benefit measurement, over what time. Reference: Constraints: Origins. Schedule. Background. Resources. Current state. Budget. Context: Staffing. Opportunities. Technical. Quotes. Other. Photos. <#>

37 Business Case Budget Approval Template Business Case Name Reason Type Cost Duration Time Major Risks Description Approved Approved, but requiring further information Date Approved Approved By <#>

38 Examples of Business Cases 1. New Post Office. 2. Fix up the current PMO (Project Management Office). 3. Software Project. 4. New Boardroom. 5. Nuclear Power Station. <#>

39 Capex Liberty Properties Is this a good example? Has it covered the business case key points? <#>

40 Capex

41 Capex CAPITAL ITEMS 2012 MIDLANDS MALL APPROVED MANDATE DATE DATE DATE DATE DATE TENDER SAVINGS/ PO NUMBER AS NO. MANDATE MANDATE SITE RFQ TENDER FIGURE OVERSPEND CAPITAL LOADED ON WORKFLOW MEETING CLOSED ADJUDICATION SAP APPROVED TECHNICAL JULY R Replacement of compressors for HPI units AP/003-CST-260-TEC-001 X /02/ /02/ /05/ /06/2012? R R R IT revitalization AP/003-CST-260-TEC-002 X /02/ /02/2012 N/A 15/03/2012 AP/002-CST-260-TEC-001 R Install new pay on foot parking system R AP/003-CST-260-TEC-003 X } /02/ /02/ /03/ /03/2012 Install parking manipulators R } AP/001-CT-260-OPS-006 / AP/002-CST-260-OPS-008 AP/001-CST-260-OPS-004 / AP/002-CST-260-OPS-007 AUGUST R Installation of BMS - carryover from 2011 AP/003-CST-260-TEC-004 X /02/ /02/ /03/ /03/ /04/2012 AP/002-CST-260-TEC-002 SEPTEMBER R Separation of power factor correction AP/003-CST-260-TEC-005 X /02/ /03/ /03/ /03/ /03/2012 R R OCTOBER R Upgrade of Extractors in Transformer Rooms 1 and 3 AP/003-CST-260-TEC-006 X /05/08 15/05/2012 R New extraction system for Transformer Room 2 AP/003-CST-260-TEC-007 X SAVINGS NOVEMBER R IT systems upgrades AP/003-CST-260-TEC-008 X Office network equipment & switches R } /02/ /02/ /03/ /03/2012 UPS (2 units) R } Upgrade headcount system to be IP based R /02/ /02/2012 N/A 26/03/2012 Upgrade fire detection panels to be IP based R /02/ /02/ /03/ /03/ /04/2012 R R Tenant monitoring R /02/ /02/ /03/ /03/ /04/2012 Contingency at 10% R Travelling & accomodation R Project cost at 10% R R Total OPERATIONS JUNE R Trolley bays in 6 Parking areas (6 bays) AP/003-CST-260-OPS-001 X /02/ /02/ /03/ /03/ /03/2012 R R R Relocation of security control room AP/003-CST-260-OPS-002 X AP/002-CST-260-OPS-003 R Total BUILDING SERVICES JULY

42 Bubble Chart What key points does one need to do a Bubble Chart? One test key points available on the previous Capex. <#>

43 Business Case The 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. Desirable: Optimum mixture of risk/cost/benefit. Viable: Project capable of delivering the product. Achievable: Product can provide the benefit. The Business Case is LIVE! Constantly updated and maintained with the best know information to assess ongoing viability of the project. <#>

44 Outputs, Outcomes and Benefits Output: Specialist product (Tangible/Intangible). Outcome: Result of the change derived from using the output. Benefit: Measurable improvement resulting from the outcome. Dis-benefit: An outcome perceived as negative by one or more stakeholders. A major building supplies wholesaler erected additional outdoor storage sheds to curb theft at a cost of R600,000. The project was a success and theft from the outdoor area reduced by 80% resulting in an increase in monthly profits of R20,000. Building maintenance costs rose by 10% annually costing an additional R120,000 but insurance premiums dropped by R2500 per month. <#>

45 Outputs, Outcomes and Benefits Continued Project outputs enable Business changes create Desired outcomes also cause measured in Side-effects and consequences realize further Benefit result in helps achieve one or more Dis-benefit Strategic objectives <#>

46 Business Case The Outline Business Case is produced in the Starting Up a Project process. It is later refined and the Detailed Business Case developed in the Initiating a Project process. It continues to be maintained and verified throughout the remainder of the project. Executive summary. Reasons. Business options. Expected benefits. Expected dis-benefits. Timescale. Costs. Investment appraisal. Major risks. <#>

47 Development Path of the Business Case Confirm benefits Confirm benefits Confirm benefits Preproject Initiation stage Subsequent delivery stage(s) Final delivery stage Post-project Verify outline Business Case Verify detailed Business Case Verify updated Business Case Develop Business Case Maintain Business Case 47

48 Benefits Review Plan The Benefits Review Plan is developed during the Initiating a Project process, updated at each stage boundary and is passed on to corporate or programme management when the project is closed. Scope of the benefits review plan. Who is accountable for benefit delivery. How to measure benefit achievement. What resources will be required for the review. Baseline measures of performance. How product performance will be reviewed. <#>

49 Detailed Business Case Content PRINCE2 An executive summary. Reasons: Why is the project required. Should be linked to organisational context. Should explain how the project will enable the achievement of corporate strategies and objectives. Reasons will be defined in the project mandate, if not seek clarification. If there is no project mandate, then what? Three basic business options concerning any investment: Do nothing this is always the starting option, the basis for quantifying the other options. Do the minimum. Do something. The difference between Do the minimum and Do something is the benefit that the investment will buy. Analysis of 3 options will provide enough information to decide between the 3 options (i.e. which presents the best value for the organisation). <#>

50 Detailed Business Case Content PRINCE2 - Continued For this level of investment, are the anticipated benefits more desirable, viable and achievable than the other options available? Business case of the chosen option should be assessed for desirability, viability and achievability on a continual basis. Any new risks and/or changes may make one of the other options more justifiable. Expected benefits: Business case should list each benefit that is claimed would be achieved by the project s outcome (for the selected business option). Define the current status of each benefit in quantifiable terms, in order to assess measurable improvements after the project has been completed. Business case defines how and when the measurement of the improvements can be made. Benefits can be financial or non-financial/cashable or non-cashable. <#>

51 Detailed Business Case Content PRINCE2 - Continued Expected benefits (Continued). Benefits should be: Aligned to corporate objectives and strategy. Mapped form the outputs and outcomes provided by the project. Quantified (with tolerance) i.e. budget. Measurable. Assigned. Clear responsibility for benefits, collectively and individually: Senior user is responsible for the set of benefits within their respective areas. Responsibility for individual benefits should be assigned to an appropriate person ideally someone within the group of users affected by that benefit. The list of expected benefits will influence the set of products that the project will provide: Products that do not directly or indirectly enable the sought-after benefits to be achieved should not be included in the project. Mapping products to outcomes and to benefits aids decision making in the planning and control of the project (based on the impact of the realisation of the expected benefits). <#>

52 Detailed Business Case Content PRINCE2 - Continued Expected benefits (Continued). Benefits should be expressed in tangible ways wherever possible. Senior user or executive can define many benefits as intangible. It is worthwhile to try to express intangible benefits measurable terms. Quantification of benefits enables benefits tolerance to be set and measurability of the benefits ensures that they can be proven. If benefits cannot be proven then it cannot be determined if a project: Has been a success. Has provided value for money. Should be (or have been) initiated. Verify expected benefits: Sensitivity analysis. Define three views of the achievement of the benefits. Build an allowance into the costs for estimating inaccuracies, changes and risks. <#>

53 Detailed Business Case Content PRINCE2 - Continued Expected dis-benefits: This is an outcome perceived as negative by one or more stakeholders. Actual consequences of an activity (a risk has some uncertainty about whether it will materialise). Timescale: Corporate and/or programme management will wish to know: Costs: Over what period the project costs will be incurred. Over what period the cost/benefits analysis will be based. When the organisation can expect to accrue benefits. What the earliest/latest feasible start date is. What the earliest/latest feasible completion date is. Business case should summarise costs derived from the project plan together with the assumptions upon which they are based. Costs should also include details of the on-going operations and maintenance costs and funding arrangements. <#>

54 Detailed Business Case Content PRINCE2 - Continued Investment appraisal: Comparison between the development, operations and maintenance costs with the value of benefits over a period of time. Over a fixed period of a number of years or the useful life of the products. Prescribed accounting rules for how the investment will be appraised may be defined by the commissioning authority. Should cover both project costs (to produce the required products and the project management costs) and on-going operations and maintenance costs. Major risks: Project board needs to understand the set of risks that may either reduce/enhance the benefits or reduce/increase the cost. In order to judge business justification. Business case should include a summary of the aggregated risk (in the form of a summary risk profile). Should highlight the major risks that will have an effect on the business objectives and benefits (covers both the project delivery and the on-going operations and maintenance). <#>

55 Typical Business Case Topics Executive summary: Highlights the key points in the business case. Includes important benefits and return on investment. Business opportunity: Describes the motivation for the project. Includes a definition, a statement of scope and a discussion of objectives that the project will help the organisation achieve. Alternatives: The business case analyses the alternatives to a proposed project. All business cases involves at least 2 alternatives: Doing a project. Not doing a project. <#>

56 Typical Business Case Topics Continued Benefits: Benefits provide three types of business value: Increased revenue. Reduced costs. Strategic advantage. Quantifying benefits that provide strategic advantage may make the difference between business case success and failure. Costs: Typical costs include: Equipment (purchase and maintenance). Labour (training and operation). Overhead cost. Recommendations: Summarise the main points of a business case and offer suggestions on how to proceed with the project. <#>

57 Typical Business Case Topics Continued Financial analysis: Compares benefits to costs. Analyses the value of a project as an investment. May include a cash flow statement, return on investment, net present value, internal rate of return and payback period. Assumptions: Events that a business case assumes will happen. Critical assumptions must occur for a project to succeed. Sensitivity analysis: Evaluates the probability that a project cam be implemented successfully. Evaluates the risks involved in undertaking the project. Risks may also result from not undertaking the project. Project description: Provide information for Project Board to decide whether the project is viable and worth doing. Implementation plan: Business case is meaningless unless project cannot be implemented successfully. <#>

58 Typical Business Case Topics Continued Constraints: Limitations that may impact the success of a project. Including: Schedule. Resource. Budget. Staffing. Technical. Other. Market analysis: Examines changes in business environment that impact the success of a project. Technological innovations and shifts in customer demographics. Organisational considerations: Examine how a project impacts an organisation. Project success might depend on management support and employee acceptance. <#>

59 Typical Business Case Contents PRINCE2 Varies from industry to industry and from project to project. Reasons: Why the project is required. How the project will enable the treatment of corporate strategies and objectives. Generally, reasons will either be to reduce pain or to increase gain of some sort. Business Options: 3 basic PRINCE2 business case options: Do nothing - is always the starting point reference for quantifying the other options. Do the minimum. Do something. Whichever option is now selected in the business case: Should show the best level of investment for the best realized benefits. Is more viable and achievable than the other options. <#>

60 Typical Business Case Contents PRINCE2 - Continued Expected benefits: Based on the selected option. A list of each business case benefit that could be achieved by the project s outcome. Defines how and when the measurement of these improvements can be made. Some benefits will be measured by financial metrics and others by non-financial metrics. Each benefit should be tied back through the products and outcomes that will provide them. Should be measurable and stated within a tolerance. Should be clearly stated in the business case where these benefits will be achieved. The PRINCE2 senior user is responsible for identifying the business case benefits in the first place. Will be held to account by corporate or programme management that these benefits are eventually realised. Expected dis-benefits: The outcome is seen as negative, and is usually the result of a side effect or consequence. Should be measurable in the same way as benefits including the use of tolerance. <#>

61 Typical Business Case Contents PRINCE2 - Continued Timescale: Extracted from the PRINCE2 project plan. Includes other time-frames: Project time-frame. Time-frame that cost/benefits analysis will be based upon. Time when benefits will be accrued. Earliest/latest feasible start and completion dates. Costs: Summarised from the PRINCE2 project plan along with their assumptions. Should also include details of on-going operational and maintenance costs. Should also include the funding arrangements. <#>

62 Typical Business Case Contents PRINCE2 - Continued Investment appraisal: Depending on the industry or organisation, then different techniques will be used for business case investment appraisal. Normally compares the development, operations and maintenance costs against the value of the benefits over a period of time. Techniques that may be used within a PRINCE2 business case most often used include: Return on investment. Payback period. Discounted cash flow. Net present value. Sensitivity analysis. Major risks: In order for the business case to make a balanced business justification. Consider and include the risks. These should be balanced against the benefits and costs. Include a summary of the aggregated risks. Mention specifically those that will have an effect on the business objectives and benefits. <#>

63 Contents of the Final Business Case Executive Summary: 3 pages for small projects, a maximum of 5 pages for complex projects. Write it as if this is the only part of the document that will be read. Should cover all the issues that a decision maker will need to know about. Outline of the proposal and the business concept. Summary analysis of the options and alternatives considered. Details of the preferred option. Use text, graphics and tables of critical numbers to present the key arguments and findings to decision makers. Cover all high-level issues that would be covered in an Executive Director s briefing. Clear, succinct summary of the service delivery requirement to be addressed: Project objectives. Options considered. Summary of evaluation of options. Project readiness. Budget and funding implications. Project risks and risk management strategies. Project profile model. Gateway (or other) reviews. Performance measures. Next steps in progressing project. <#>

64 Calculating Financial Metrics Return On Investment (ROI): Profits or savings resulting from investments (this is the same as net benefits if benefits were only financial). ROI% = Payback Period (PBP): (Benefits Cost) Cost Calculating the period of time required for the ROI to repay the sum of the original investment. Net present value (NPV): The total value of discounted future cash inflows less the initial investment. Based on the time value of money, how much is the project worth right now minus the cost of the project. NPV = PV Cost Of Project Ex: if inflation is at 6% the value of money halves approximately every 12years. If a project is forecasting a SZL benefit to materialise in year 12, then it is only worth ZSL in today s money. <#>

65 Calculating Financial Metrics Continued Present Value (PV): Based on the time value of money, how much is the project worth right now. Benefit Cost Ratio (BCR): This ratio compares the benefits to the costs of different options. >1 benefits are greater than costs. <1 costs are greater than benefits. =1 benefits and costs are the same. Economic Value Added (EVA): How much value has a project truly created for its shareholders. EVA = After Tax Profits Capital Invested in project x Cost Of Capital Internal Rate of Return (IRR): Project s returns expressed as an interest rate. Return on Invested Capital (ROIC): How an organisation uses the money invested in a project and it is expressed as a percentage. ROIC = Net Income (after tax) from Project Total Capital Invested in the Project <#>

66 Detailed Costs PRINCE2 The project has to be affordable and though we may start out with a particular budget in mind there will be many factors which can lead to overspending and perhaps some opportunities to cut costs. Cost tolerance: The permissible deviation on a plan s cost that is allowed before the deviation needs to be escalated to the next level of management. Cost tolerance is documented in the respective plan. Plus or minus an amount of time on the planned budget. The business case should summarise the costs derived from the project plan together with the assumptions upon which they are based. The costs should also include details of the on-going operations and maintenance costs and their funding arrangements. Through-life costs: Analysing the total cost of implementation and any incremental operations and maintenance costs. Full project costs can only be estimated once the quality criteria for the products and the quality management activities which have to be included in the project s plans have been established. Project plan provides the business case with planned project costs. <#>

67 Detailed Costs PRINCE2 - Continued The budget should include: Costs of the activities to develop and verify the specialist products, and the cost of the project management activities. Risk budget (optional). Change budget (optional). Cost tolerance. In order to refine the business case, the outline business case (produced during Starting up a project) must be updated to reflect the estimated time and costs as determined by the Project Plan. PRINCE2 recommends that the detailed business case be created using the additional detail gained, namely: Costs and timescales as calculated in the project plan. Major risks that affect the viability and achievability of the project (from the Risk Register). Benefits to be gained. Tolerances allowed for each of the benefits. <#>

68 Detailed Costs PRINCE2 - Continued 2 of the actions recommended by PRINCE2 when authorising new work packages or authorising amendments to existing ones: Examine the stage plan for the current management stage in order to understand the: Products to be produced. Cost and effort that the work is expected to consume. Tolerances available. Define each work package to be authorised (or amended): Obtain the relevant product descriptions for inclusion in the work package. Define the techniques processes and procedures to be used. Define the development interfaces to be maintained. Define the operational and maintenance interfaces to be maintained. Define the configuration management requirements. Define the joint agreements on effort, cost, start and end dates, key milestones and tolerances. Define any constraints that may apply. Define the reporting, problem handling and escalation arrangements. Define the approval method. Provide relevant references. <#>

69 Detailed Costs PRINCE2 - Continued One of the actions recommended by PRINCE2 when updating the business case: Examine and review, amongst other elements, the project plan to see whether the cost of delivering the project s products has changed, which may affect the cost/benefit analysis. When a project closes project costs should no longer be incurred. Project-level time and cost tolerances will be defined by the programme. The customer s business case covers the benefits to that customer in contrast to its whole-life costs and risks. The costs should include: The internal costs (of customer projects resources, and on-going operations and maintenance resources). The external costs (of suppliers goods and services). Cost of conducting the gateway reviews should be included in the Project Plan and Stage Plans. One of the actions recommended by Prince 2 when planning the initiation stage: Identify any constraints on time and costs for the initiation stage. <#>

70 Project Cost Management Overview Estimate costs: The process of developing an approximation of the monetary resources needed to complete project activities. Determine budget: The process of aggregating the estimated costs of individual activities or work packages to establish an authorised cost baseline. Control costs: The process of monitoring the status of the project to update the project budget and managing changes to the cost baseline. <#>

71 Estimate Costs: Inputs, Tools & Techniques and Outputs Create WBS Develop Schedule Develop Human Resource Plan Identify Risks Enterprise/ Organisation Scope Baseline Project Schedule Human Resource Plan Risk Register Organisational Process Assets Enterprise Environmental Factors Estimate Cost Basis of Estimates Project Document Updates Activity Cost Estimates Determine Budget Project Documents Plan Procurement Identify Risks

72 Estimate Costs: Tools & Techniques Expert judgment: Cost estimates are influenced by numerous variables such as labour rates, material costs, inflation, risk factors and other variables. Analogous estimating: Uses values of parameters or measures of scale, from a previous, similar project as the basis for estimating the same parameter or measure for a current project. Parametric estimating: Uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters such as cost, budget and duration. Three-point estimates: The accuracy of single-point activity cost estimates can be improved by considering estimation uncertainty and risk. Most Likely. Optimistic. Pessimistic. <#>

73 Estimate Costs: Tools & Techniques Continued Reserve analysis: Cost estimates may include contingency reserves (sometimes called contingency allowance) to account for cost uncertainty. Cost of quality: Assumptions about costs of quality may be used to prepare the activity cost estimate. Project management estimating software: Project management cost estimating software applications, computerised spread sheets, simulation and statistical tools are becoming more widely accepted to assist with cost estimating. Vendor bid analysis: Cost estimating methods may include analysis of what the project should cost, based on the responsive bids from qualified vendors. Bottom-up estimating: This method is used to estimate one component of work. <#>

74 Estimating Costs - Techniques Historical data/information. Experience. Top-down Estimating: Good overall estimate arrived at for the plan (by whatever means). Subdivided through the levels of the product breakdown structure. Apportion the effort accordingly. Bottom-up Estimating: Each individual piece of work is estimated on its own merit. These are then summed together to find the estimated efforts for the various summary level activities and overall plan. Top-down and bottom-up approach: An overall estimate is calculated for the plan. Individual estimates are then calculated or drawn from previous plans. To represent the relative weights of the tasks. The overall estimate is then apportioned across the various summary and detailed-level tasks. Using the bottom-up figures as weights. <#>

75 Estimating Costs Techniques Continued Comparative Estimating: Historical data built up over time by an organisation regarding projects that it has undertaken (previous experience or lessons learned). This data may be useful to reference it for similar projects and apply that data to estimates. Parametric Estimating: Basing estimates on measured / empirical data where possible. Single-point Estimating: Sample data is used to calculate a single value which serves as a best guess for the duration of an activity. Three-point Estimating: Ask appropriately skilled resources for their best-case, most likely and worst-case estimates. Project manager should choose the weighted average of these three estimates. Delphi Technique: Relies on obtaining group input for ideas and problem solving without requiring face-to-face participation. Uses a series of questionnaires interspersed with information summaries and feedback from preceding responses to achieve an estimate. <#>

76 Preparing Cost Estimates Decide how much time and resources are required to carry out a piece of work to acceptable standards of performance. How: Identify the type of resource required. Specific skills may be required depending on the type and complexity of the plan. Requirements may include non-human resources. Estimating the effort required for each activity by resource type. At this point estimates will be approximate and therefore provisional. Estimating does not guarantee accuracy. When applied it provides an overall view of cost and time required to complete the plan. Estimates change as more information is collected about the project. Estimates should be challenged the same work under the same conditions can be estimated differently by various estimators or by the same estimator at different times. <#>

77 Rules for Estimating Costs Assume that resources will only be productive for 80% of their time. Resources working on multiple projects take longer to complete tasks because of time lost switching between them. People are generally optimistic and often underestimate how long tasks will take. Make use of other people s experiences and your own. Ensure that the person responsible for creating the product is also responsible for creating the effort estimates. Always build in provision for problem solving, meetings and other unexpected events. Cost each activity rather than trying to cost the plan as a whole. Communicate any assumptions, exclusions or constraints you have to the user(s). <#>

78 Financial Value for Non-Financial Objectives Objectives: Something towards which work is to be directed. A strategic position to be attained. A purpose to be achieved. A result to be obtained. A product to be produced. A possibility for positive changes. Contrast with threat. <#>

79 Detailed Benefits PRINCE2 The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders. Benefits Review Plan: A plan that defines how and when a measurement of the achievement of the project s benefits can be made. If the project is being managed within a programme, this information may be created and maintained at the programme level. Benefits tolerance: The permissible deviation in the expected benefit that is allowed before the deviation needs to be escalated to the next level of management. Benefits tolerance is documented in the business case. Once benefits have been quantified the benefits tolerance can be set. The measurability of the benefits ensures that they can be proven. Perhaps most often overlooked is the question: Why are we doing this? The project manager has to have a clear understanding of the purpose of the project as an investment and make sure that what the project delivers is consistent with achieving the desired return. Benefits of a project are often only realised after project closure. Link from projects outputs to outcomes and benefits should be clearly identified and made visible to those involved this is the original purpose of the project. <#>

80 Detailed Benefits PRINCE2 - Continued Expected benefits: Each benefit should be listed in the business case. Current status of each benefit should be defined in quantifiable terms in order to assess the measurable improvements after the project has been completed. Financial or non-financial. Benefits should be: Aligned to corporate objectives and strategy. Mapped from the outputs and outcomes provided by the project. Quantified (with tolerance). Measurable. Assigned. Successful benefit realisation will be dependent on clear responsibility assignment. Expected benefits influence the set of products that the project will provide. Mapping products to outcomes and subsequently to benefits will aid decision making in the planning and control of the project. Always expressed in tangible ways. <#>

81 Detailed Benefits PRINCE2 - Continued Expected benefits (continued). Always attempt to express seemingly intangible benefits in measurable ways. Benefits that cannot be proven makes it impossible to judge whether the project: Has been a success. Has provided value for money. Should be / have been initiated. Verifying expected benefits: Sensitivity analysis determine whether or not the business case is heavily dependent on a specific benefit. Define 3 views of the achievement of benefits what is really expected, what is the bestcase scenario and what is the worst-case scenario. This reveals whether benefit expectations are reasonable or overoptimistic. Once benefits have been defined, activities to establish and collect measures should be described in the benefits review plan. Expected dis-benefits: An outcome perceived as negative by one or more stakeholders. An actual consequence of an activity. <#>

82 Detailed Benefits PRINCE2 - Continued Net benefits: Analysing the total value of the benefits less the cost of implementation and ongoing operation calculated over a defined period. Project closure activities include: Planning post-project benefits reviews to take place for those benefits that can only be assessed after the products have been in use. Thus after the project has closed. Create the detailed business case by updating the outline business case with the following additional detail: The costs and timescale as calculated in the project plan. The major risks that affect the viability and achievability of the project (from the Risk Register). The benefits to be gained. The tolerances allowed for each of the benefits. <#>

83 Detailed Benefits PRINCE2 - Continued Confirming benefits: Identify the benefits. Select objective measures that reliably prove the benefits. Collect the baseline measures (from which the improvements will be quantified). Decide how, when and by whom the benefit measure will be collected. <#>

84 Benefit Measurement Methods Comparative Approach Murder board (a panel of people who try to shoot down a new project idea). Peer review. Scoring models. Economic models: Present value. Net present value. Internal rate of return. Payback period. Benefit-cost ratio. <#>

85 Benefit Measurement Methods Comparative Approach Economic Models (Continued) Present Value: The value today of future cash flows: PV = FV / (1 + r) n Net Present Value: Present value of the total benefits (income or revenue) minus the costs over many time periods (a positive value indicates a good investment and the greater the value the better the investment). Internal Rate of Return: The interest rate at which the project inflows (revenues) and project outflows (costs) are equal (the greater the value the more desirable the project). Payback Period: The length of time it takes to recover your investment in the project before you start accumulating profit (the shorter the payback period the more desirable the project). Benefit-Cost Ratio: Relates to costing projects and to determining what work should be done. This ratio compares the benefits to the costs of different options. If this ratio is greater than 1 it means that the benefits are greater than the costs, if this ratio is less than 1 it means that the costs are greater than the benefits and if this ration is equal to 1 it means that the benefits and the costs are the same. <#>

86 Tangible and Intangible Benefits Tangible (Hard) Benefits: H1 Production of material, software, services, processes, etc. H2 Improved collaboration. H3 Improved awareness of the ideas, concepts, materials, etc. within the institution, the sector and other wider areas e.g. government or the general public. H4 Improved skills and attitudes of users, project team, institution staff, stakeholders and staff in sector. Intangible (Soft) Benefits: S1 Catalyst for change both in institution and wider. S2 Impact on professional or governmental views, actions or policies. S3 Improvement of image, standing or effectiveness of the funding body of the project. S4 Improvement of image, standing or effectiveness of the institution. S5 Improvement of image, standing or effectiveness of the project team. <#>

87 Detailed Business Case Approach The business case must first be: Developed, meaning it contains the right information. Verified, meaning that the project is still worthwhile. Maintained, meaning that the business case is updated with actual costs and benefits for both current and forecast time-frames. Confirmed, meaning assessing whether the benefits have been, or will be realised. The project board executive is responsible for the business case. The development of the business case as above may be delegated to the project manager or someone else with appropriate finance knowledge and skills including the business assurance role if the executive has delegated their responsibilities. The business case will be reviewed: At the end of the starting up a project process. At the end of the initiating a project process. The business case will form part of the evidence the project board uses to decide what to do next. During a stage and as part of any impact assessment for issues or risks, the business case should be checked to see what the impact may be. 87

88 Detailed Business Case Approach Continued At the end of each stage the project manager will update the business case based on the next stage plan, and also update the project plan, this will be presented to the project board for them to decide what to do next. The investment appraisal section of the business case provides the project with information to verify that it justifies the authorization and continuation of the project. The senior user is responsible for specifying the benefits within the business case and will be held accountable by corporate or programme management for the eventual realisation of the forecast benefits. The benefits review plan is created from the detailed business case during the initiation stage, and this will be updated at the end of each stage as part of the evidence for the project board to consider as to whether to proceed or not. The project s benefits review plan defines the scope, timing and responsibility of a number of reviews for the expected benefits. The benefits that can be measured during a project should be included in each end stage report. <#>

89 Detailed Business Case Approach Continued The business case in PRINCE2 is the document against which all decisions are ultimately made. It provides the decision makers (project board) in the project with a clear picture of what the project is set to deliver, how much it is all going to cost, how long it will take, and an analysis of when the expected benefits will come on stream. So why is this any different to any other project that we already undertake? For example at home; if we are considering enlarging our living accommodation we first of all have to gain a common understanding of why we need to do it, to have good REASONS. Once that is agreed and decided there are several options that may be available to us: We could do nothing. We could move to a larger house. We could build an extension on side of the existing house. We could grow into the loft. We could adapt the existing room layout. Each of these OPTIONS would of course have different costs and timescales attached to them, but we would consider them all, and decide which of them could be discounted and capture why that decision was made. We may be left with a couple of alternatives which need further investigation, but eventually we come to a decision on the way forward, and that is our chosen OPTION. <#>

90 Detailed Business Case Approach Continued The business case is developed at the beginning of the project: Getting the right information upon which decisions can be made. Executive is responsible for ensuring that the business case written and approved. This task may be delegated (to a business analyst or project manager). It is essential to ensure that, whoever is assigned the task of developing the business case has the appropriate business skills required. Alternatively the project board should consider using project assurance to assist with the development of the business case. The outline business case is: Derived from the project mandate. Developed pre-project in the starting up a project process. To gain approval by the project board in the directing a project process to initiate the project. Outline business case stands until the project has been planned in detail. Outline business case is based on approximate costs and timescales. <#>

91 Detailed Business Case Approach Continued The detailed business case is derived from the: Outline business case. Project plan (costs, timescale, products). Risk register. Throughout the project life cycle the business case will be developed over and over again. Initial justification is needed to proceed with the project. Better understanding of the costs and timescales may: Increase/decrease the desirability, viability and achievability of the project. Change the project approach. Lead to some re-planning. <#>

92 Detailed Business Case Approach Continued The business case is maintained throughout the life of the project: The business case is updated with actual costs and benefits and current forecasts for costs and benefits. The business case drives all decision making: Ensures that the project remains justified and that the business objectives and benefits being sought can be realised. The business case should be reviewed: At the end of the starting up a project process by the project board. At the end of the initiating a project process by the project board. As part of any impact assessment by the project manager. In tandem with an exception plan by the project board. At the end of each stage by the project manager. At the end of each stage by the project board. During the final stage by the project manager. As part of the benefits review. <#>

93 Detailed Business Case Approach Continued The Executive is responsible for assuring the project s stakeholders that the project remains desirable, viable and achievable at all times, using end stage assessments and project assurance. Investment appraisal section of the business case provides information to verify that the business case justifies the authorisation or continuation of the project. The business case is formally verified by the project board at each key decision point (i.e. end stage assessments). Assess whether the project is still worthwhile. <#>

94 Detailed Business Case Approach Continued The business case is confirmed throughout the period that the benefits accrue: Assess whether the intended benefits have been/will be realised. This will most likely take place post-project. Approach to confirming benefits: Identify the benefits. Select objective measures that reliably prove the benefits. Collect the baseline measures (from which the improvements will be quantified). Decide how, when and by whom the benefit measure will be collected. Senior users must specify the benefits and are held accountable for demonstrating to corporate/programme management that the forecast benefits that formed the basis of project approval are in fact realised. Commitment beyond the life of the project is necessary, since many benefits will not be realised until after it has closed and once the project closes, the temporary organisation is disbanded along with the framework (including funding and resources) needed to carry out any measurement activities. PRINCE2 defines a benefit review plan. It will use the detailed business case to define the scope, timing and responsibility of a number of reviews based on the timing and nature of the expected benefits. <#>

95 Detailed Business Case Approach Continued The Executive is responsible for ensuring that benefit reviews are planned and executed. Exceptions: Projects in a programme environment: o Benefits review plan may be produced and executed by the programme. o Coordinating the realisation of benefits of its projects is one of the roles of a programme. If the corporate organisation has a centre of excellence or some form of performance monitoring unit: o It may take the responsibility for measuring benefits of all projects within the organisation. Post-project measurement activities: o Responsibility will transfer from the executive to corporate/programme management as the project closes. o As the reviews will need to be funded and resourced. <#>

96 Detailed Business Case Approach Continued Benefits review plan: First created by the project manager. In the initiation stage. Submitted to the project board for approval. When seeking project authorisation. If corporate or programme management are to manage or participate in the benefits reviews project board may need to seek approval from corporate or programme management. It is updated towards the end of each stage with actual benefits achieved. A revised plan is created for any remaining reviews whether within or beyond the life of the project. PRINCE2 recommends that the benefits review plan is kept separate from the project plan and stage plans. Benefits that can be measured during the life of a project should be reported by the project manager in the end stage report. Any other benefits should be re-examined and their forecast updated as part of the managing a stage boundary process. <#>

97 Detailed Business Case Approach Continued Post-project benefits review involves: Corporate or programme management. The senior user being held to account. Asking senior users to provide evidence of how the individual benefits allocated to them have been gained in comparison to those benefits promised to justify the cost and risk of the project when it was authorised. Review of performance of project s products in operational use. Identifying whether there have been any side-effects (beneficial/adverse) that may provide useful lessons for other projects. The business case is at the centre of any impact assessment of risks, issues and changes. How will this risk, issue or change affect the viability of the business case and the business objectives and benefits being sought? <#>

98 Credibility, Practical Value and Accuracy of the Board Credibility: of Project Board members within the corporate organisation will affect their ability to direct the project. Accuracy: Means that the measured value is very close to the true value. A very accurate measure is not necessarily precise. Project Management team must determine appropriate levels of accuracy and precision. Level of accuracy. Activity cost estimates will adhere to a rounding of the data to a prescribed precision, based on the scope of the activities and magnitude of the project, and may include an amount for contingencies. Precision means the values of repeated measurements are clustered and have little scatter. A very accurate measurement is not necessarily precise. If business cases are weak: What effect will this have on strategy? How much time will be spent reviewing and approving business cases/projects? What effect will it have on the company? <#>

99 Risk Breakdown Structure Risks Internal Risks External Risks Functionality too limited Integration Problems with backend systems Data Centre Unable to Support Technology Selected Technology Unproven Functionality Manager's Resistance to Project Shifts in customer needs Trading partners won't adopt Competition first to market Protocol Problems 99

100 Risk Analysis PMP Risk: A risk is any unknown on the project. Risks may be positive or negative. An uncertain event or set of events, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives. Risk Acceptance: the decision to deal with the risk if and when it occurs, when risk acceptance is employed, no additional planning or steps will be taken before the risk event occurs. Risk avoidance: Taking steps to eliminate the project risk. Risk Breakdown Structure: A graphical chart showing risks organised into categories, this organisation will vary from project to project. Risk Database: the risk database contains all information on identified risks throughout the life of the project. The risk database will be used by future projects to assist in risk analysis. Risk Enhancement: A risk management strategy for making a positive uncertainty even better for the project. Risk Exploitation: a risk management strategy for making a positive uncertainty more likely to occur. Risk management plan: the component of the project plan that shows how subsequent risk processes and activities will be performed. <#>

101 Risk Analysis PMP Continued Risk mitigation: looking to decrease either the likelihood of an identified risk s occurrence, or its impact on the project if it does occur. Risk register: the document containing all identified risks relevant to the project. the risk register, which is a component of the project plan, contains information about each risk and is updated throughout the project. Risk transference: the risk response technique of shifting the risk to another entity, usually a subcontractor of a vendor specialising in that type of risk. Firm fixed price contracts would be one type of risk transference, as would be purchasing an insurance policy that protected the project. Risk actionee: a nominated owner of an action to address a risk. Some actions may not be within the remit of the risk owner to control explicitly; in that situation there should be a nominated owner of the action to address the risk. They will need to keep the risk owner informed of the situation. Risk appetite: an organisation s unique attitude towards risk taking that in turn dictates the amount of risk that it considers is acceptable. Risk estimation: the estimation of probability and impact of an individual risk, taking into account predetermined standards, target risk levels, interdependencies and other relevant factors. <#>

102 Risk Analysis PMP Continued Risk evaluation: the process of understanding the net effect of the identified threats and opportunities on an activity when aggregated together. Risk management: the systematic application of principles, approaches and processes to the tasks of identifying and assessing risks, and then planning and implementing risk responses. Risk management strategy: a strategy describing the goals of applying risk management, as well as the procedure that will be adopted, roles and responsibilities, risk tolerances, the timing of risk management interventions, the tools and techniques that will be used, and the reporting requirements. Risk owner: a named individual who is responsible for the management, monitoring and control of all aspects of a particular risk assigned to them, including the implementation of the selected responses to address the threats or to maximise the opportunities. Risk profile: a description of the types of risk that are faced by an organisation and its exposure to those risks. Risk response: actions that may be taken to bring a situation t a level where exposure to risk is acceptable to the organisation. <#>

103 Risk Analysis PMP Continued Risk tolerance: the threshold levels of risk exposure which, when exceeded, will trigger an Exception Report to bring the situation to the attention of the Project Board. Risk tolerances could include limits on the plan s aggregated risks, or limits on any individual threat. Risk tolerance is documented in the Risk Management Strategy. Risk Tolerance Line: A line drawn on the summary risk profile. Risks that appear above this line cannot be accepted (lived with) without referring them to a higher authority. Analyse the risk: this is a planning activity that will run parallel with other steps because risks may be identified at any point in the creation or revision of a plan. Examine each resource and activity for potential risk content. Identified risks should be entered in the risk register. <#>

104 Threat and Opportunity Responses Threat Responses0 Avoid Opportunity Responses Exploit Reduce (probability and/or impact) Fall back (reduces impact only) Enhance Transfer (reduces impact only, and often only the financial impact) Share Accept Reject <#>

105 Probability Probability Impact Grid Very High 71-90% High 51-70% Medium 31-50% Low 11-30% Very low Up to 10% Very low Low Medium High Very high Impact 105

106 Identify Risks: Inputs and Outputs Inputs Risk Management Plan Activity Cost Estimates Activity Duration Estimates Scope Baseline Stakeholder Register Cost Management Plan Schedule Management Plan Quality Management Plan Project Documents Enterprise Environmental Factors Organisational Process Assets Risk Register Outputs 106

107 Perform Qualitative Risks Analysis The process of prioritising risks for further analysis or action by assessing and combining their probability of occurrence and impact Risk Register Inputs Risk Management Plan Project Scope Statement Organisational Process Assets Outputs Risk Register Updates 107

108 Perform Qualitative Risk Analysis Data Flow Diagram Define Scope Plan Risk Management Identify Risks Project Scope Statement Risk Management Plan Risk Register Enterprise / Organisation Organisational Process Assets Perform Qualitative Risk Analysis Risk Register Updates 108

109 Perform Quantitative Risks Analysis The process of numerically analysing the effect of identified risks on overall project objectives Risk Register Inputs Risk Management Plan Cost Management Plan Schedule Management Plan Organisational Process Assets Outputs Risk Register Updates 109

110 Perform Quantitative Risk Analysis: Inputs, Tools & Techniques and Outputs Project Time Management Project Cost Management Enterprise / Organisation Schedule Management Plan Cost Management Plan Organisational Process Assets Plan Risk Management Risk Management Plan Perform Quantitative Risk Analysis Identify Risks Risk Register Risk Register Updates 110

111 Plan Risk Responses Risk Register Inputs Risk Management Plan Outputs Risk Register Updates Risk-related Contract Decisions Project Management Plan Updates Project Document Updates 111

112 Risk Calculation Calculation: Risk Response: Issue Response: Probability x Impact = % risk 112

113 The Purpose and Objective of Initiating Purpose of process is to establish solid foundations for the project, enabling the organisation to understand the work that needs to be done to deliver the project s products before committing to a significant spend. Objective of process is to ensure a common understanding of: The reasons for doing the project, benefits expected and associated risks. Scope of what is to be done and products to be delivered. How and when project s products will be delivered and at what cost. Who is to be involved in the project decision making. How the quality required will be achieved. How baselines will be established and controlled. How risks, issues and changes will be identified, assessed and controlled. How progress will be monitored and controlled. Who needs information, in what format at what time. How the corporate project management method will be tailored to suit the project. <#>

114 The Context and Activities of Initiating Context: Foundation. Allows project board to decide whether the project is properly aligned with corporate objectives to authorise it continuation. If there is a commercial relationship between the customer and supplier all activities within the initiating a project process need further consideration. The project manager will be creating the suite of management products required for the level of control specified by the project board. Activities: Prepare the risk management strategy. Prepare the configuration management strategy. Prepare the quality management strategy. Prepare the communication management strategy. Set up the project controls. Create the project plan. Refine the business case. Assemble the project initiation documentation. <#>

115 The Purpose and Objective of Delivering Purpose is to control the link between the project manager and the team managers by placing formal requirements on accepting, executing and delivering project work. The team manager s role is to coordinate an area of work that will deliver one or more of the project s products. Objective is to ensure: Work allocated to team is authorised and agreed. Team managers, team members and suppliers are clear as to what is to be produced, expected effort, cost or timescales. The planned project is delivered to expectations and within tolerance. Accurate progress information is provided to the project manager at an agreed frequency to ensure that expectations are managed. <#>

116 The Context and Activities of Delivering Context: The team manager ensures delivery by: Accepting and checking authorised work packages form Project manager. Ensuring that interfaces identified in the work packages are maintained. Creating a team plan for the work packages being assigned. Ensuring that development is in accordance with any development methods specified in the work package. Demonstrating that each product meets its quality criteria. Obtaining approval for completed products from the authorities identified in the product description. Delivering the products to the project manager in accordance with any procedures specified in the work package. Activities: Accept a work package. Execute a work package. Deliver a work package. <#>

117 The Purpose and Objective of Closing Purpose is to provide a fixed point at which acceptance for the project product is confirmed and to organise that objectives set out in the original project initiation documentation have been achieved. Objective is to: Verify user acceptance of the project s products. Ensure that the host site is able to support the products when the project is disbanded. Review the performance of the project against its baselines. Assess any benefits that have already been realised, update the forecast of the remaining benefits and plan for a review of those unrealised benefits. Ensure that provision has been made to address all open issues and risks, with follow-on action recommendations. <#>

118 The Context and Activities of Closing Context: PRINCE2 projects are finite. A clear end to a project: More successful. Provides opportunity to ensure that all unachieved goals and objectives are identified so that they can be addressed in the future. Transfer ownership of the products to the customer and terminates the responsibility of the project management team. Closure activities should be planned as part of stage plan for final management stage. Project board may want to trigger premature project closure of the project under some circumstances. Activities: Prepare planned closure. Prepare premature closure. Hand over products. Evaluate the project. Recommend project closure. <#>

119 Making Assumptions PRINCE2 A statement that is taken as being true for the purposes of planning, but which could change later. An assumption is made where some facts are not yet known or decided. An assumption is usually reserved for matters of such significance that, if they change or turn out not to be true, there will need to be considerable re-planning. <#>

120 Making Assumptions PMBoK Assumptions are factors that, for planning purposes, are considered to be true, real or certain without proof or demonstration. The constraints and assumptions from the project scope statement are considered when estimating the activity durations. Examples of assumptions include: Existing conditions. Availability of information. Length of the reporting periods. Examples of constraints include: Available skilled resources. Contract terms and requirements. Assumptions analysis: Every project and identified project risk is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, instability, inconsistency or incompleteness of assumptions. <#>

121 Making Assumptions Continued Constraints and assumptions: Constraints are factors that limit the team s options such as limits on resources, budget, schedule and scope. Assumptions are things that are assumed to be true but that may not be true. Constraints and assumptions are recorded in the project scope statement. Constraints and assumptions are inputs to many project management processes. Identified and then managed. Sponsor, team and other stakeholders can identify constraints and assumptions and review them for validity throughout the life of the project. If the constraints change or the assumptions are proven wrong the project management plan may need to change. Assumptions analysis is part of the risk management process. Historical records can be used to validate assumptions. An assumption is anything that is considered to be true while planning. Assumptions should always be documented and validated, and they are often closely linked to constraints. <#>

122 Portfolio, Programme and Project Management Interactions Lower Level Portfolio Strategies & priorities Progressive elaboration Governance Disposition on requested changes Impacts from changes in other portfolios, programs or projects Performance reports Change requests with impact on other portfolios, programs or projects Highest Level Portfolio Strategies & priorities Progressive elaboration Governance Disposition on requested changes Impacts from changes in other portfolios, programs or projects Performance reports Change requests with impact on other portfolios, programs or projects Projects Projects Higher Level Programs Lower Level Programs Strategies & priorities Progressive elaboration Governance Disposition on requested changes Impacts from changes in other portfolios, programs or projects Performance reports Change requests with impact on other portfolios, programs or projects Higher Level Programs Lower Level Programs Projects Projects Projects 122

123 PRINCE2 Processes Pre-project Initiation stage Subsequent delivery stage(s) Final delivery stage Directing Managing Starting up a project Managing a stage boundary Initiating a project Directing a project Controlling a stage Managing a stage boundary Closing a project Controlling a stage Delivering Managing product delivery Managing product delivery 123

124 Project Boundaries Project Boundaries Planning Processes Project Initiator / Sponsor Project Inputs Initiating Processes Monitoring & Controlling Processes Closing Processes Project Deliverables Project Records End Users Process Assets Executing Processes 124

125 Project Life Cycle and Organisation Project Stakeholders Other Stakeholders Sponsor Operations Management Portfolio Manager Project Team Functional Managers Program Manager Project Management Office Project Management Team Project Manager Other Project Team Members Customers / Users Sellers / Business Partners The Project 125

126 Business Case Approval Process What is your Business Case approval process?

127 The business case development and approval process The development and approval process should be designed to be: Adaptable - tailored to the size and risk of the proposal. Consistent - the same basic business issues are addressed by every project. Business oriented - concerned with the business capabilities and impact, not a technical focus. Comprehensive - includes all factors relevant to a complete evaluation. Understandable - content is relevant & logical, demanding yet simple to complete & evaluate. Measurable - all key aspects can be quantified in order to track and measure achievement. Transparent - key elements can be justified directly. Accountable - clear accountabilities & commitments for benefit delivery & cost management. Development of the business case should not be mechanical. The process of developing a business case involves: Financial decomposition. Opportunity identification. Opportunity qualification. Benefit validation. Finalization of the business case. <#>

128 What a Business case is not / should not be No stories No long winded paragraphs (Must be in point form) As short as possible to give the information Get to the point! (Must sell the project) Must not be vague Must not be one of the other project documents Specification Project Plan <#>

129 Project management fundamentals

130 The Project Manager s Power By Organisation Type Less formal authority Functional Functional Manager Stronger Weak Matrix Balanced Matrix Power Shared Between Project and Functional Manager Strong Matrix Projectized Project Manager Stronger More formal authority

131 What Is A Project Manager? The person assigned by the performing organisation to achieve the project objectives. Characteristics of a project manager: Knowledge what the project manager knows about project management. Performance what the project manager is able to do or accomplish while applying their project management knowledge. Personal how the project manager behaves when performing the project or related activity. Personal effectiveness encompasses attitudes, core personality characteristics and leadership the ability to guide the project team while achieving project objectives and balancing the project constraints. The project manager must address every process to determine the level of implementation for each process for each project. If a project has more than one phase, the same level of rigor should be applied to processes within each phase of the project. The role of the person ultimately responsible for the project. The project manager has the authority to spend project budget and to assign project resources in order to realise the project s goals.

132 What Is A Project Manager? Continued The Project Manager is: Formally empowered to use organisational resources. In control of the project. Authorised to spend the project s budget. Authorised to make decisions for the project. Management skills: Leading. Communicating. Negotiating. Problem solving. Influencing. Competencies: Planning. Time management. People management. Problem solving. Attention to detail. Communication. Negotiation. Conflict management.

133 What Is A Project Manager? Continued Project manager controls: Authorisations. Progress updates. Exceptions and changes. Four levels of management: Corporate or programme management. Directing. Managing. Delivering.

134 What Is A Project Manager? Continued Responsibilities: Prepare the following baseline management products, in conjunction with any project assurance roles and agree them with the project board: Project brief, including project product description. Benefits review plan. Project initiation documentation. Stage/exception plans and their product descriptions. Work packages. Prepare the following reports: Issue reports. End stage reports. Lessons reports. Exception reports. End project reports. Maintain the following records: Issue register. Risk register. Daily log. Lessons log.

135 What Is A Project Manager? Continued Liaise with corporate or programme management. Liaise with any external suppliers or account managers. Lead and motivate the project management team. Ensure that behavioural expectations of team members are established. Manage the information flows between the directing and delivering levels of the project. Manage the production of the required products, taking responsibility for overall progress and use of resources and initiating corrective action where necessary. Establish and manage the project s procedures. Establish and manage the project controls. Authorise work packages. Advise the project board of any deviations from the plan. Unless appointed to another person(s), perform the team manager role. Unless appointed to another person(s), perform the project support role. Implement the configuration management strategy. Ensure project personnel comply with the configuration management strategy. Schedule configuration audits.

136 What Is A Project? A temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case. A temporary endeavour with a beginning and an end which creates a unique product, service or result. A time-limited undertaking to deliver a unique product, service or outcome. Unique means that it has never been performed by this organisation before. Projects do not include on-going operations, although they do need to consider them upfront. A temporary (finite) group of related tasks undertaken to create a unique product, service or result. The project ends when the objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists. Organisational influences on project management. Organisational cultures and styles.

137 What Is A Project? Continued Organisational structure: Functional organisation. Weak matrix organisation. Balanced matrix organisation. Strong matrix organisation. Projectised organisation (i.e. the entire company is organised by projects). Composite organisation. Organisational process assets: Processes and procedures. Corporate knowledge base. Projects and strategic planning. Projects are often used to achieve an organisation s strategic plan. Projects are usually authorised because of one or more of the following strategic considerations: Market demand. Strategic opportunity/business need. Customer request. Technological advance. Legal requirements.

138 What Is Project Management? The application of knowledge, skills, tools and techniques to project activities to meet the project requirements. Project management processes: Initiating. Planning. Executing. Monitoring and controlling. Closing. Managing a project typically includes: Identifying requirements. Addressing the various needs, concerns and expectations of the stakeholders as the project is planned and carried out. Balancing the competing project constraints including, but not limited to: Scope. Quality. Schedule. Budget. Resources. Risk.

139 What Is Project Management? Continued Project management office: is an organisational body or entity assigned various responsibilities related to the centralised and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project. Primary function: To support project managers in a variety of ways. Project processes performed by the project team: Project management processes. Product-oriented processes.

140 Project Life Cycle

141 Degree Impact of Variable Based on Project Time High Stakeholder influence, risk and uncertainty Cost of changes Low Project Time

142 Cost and Staffing level Typical Cost and Staffing Levels Across the Project Life Cycle Starting the project Organising and preparing Carrying out the work Closing the project Project Management Outputs Project Charter Project Management Plan Accepted Deliverables Archived Project Documents Cost and Staffing level

143 Project Life Cycle

144 Stage What is a stage? Why have a stage? Control. Measurement.

145 Stages/Steps/Phases Stage/Step/Phase 1: Proposal. Business case. Feature pack. Scope of work. Stage/Step/Phase 2: Solution design. Analysis. Requirements. Stage/Step/Phase 3: Planning. Stage/Step/Phase 4: Execution. Stage/Step/Phase 5: System testing (internal). Stage/Step/Phase 6: Implementation. UAT (user acceptance testing). Stage/Step/Phase 7: Go live. Hand over to support. Stage/Step/Phase 8: Customer hand over. Snag fixing. Training & support. Stage/Step/Phase 9: Close. Lessons learnt. Project audit. Stage/Step/Phase 10: Benefits measurement. Customer satisfaction.

146 Project Life Cycle

147 Project Management Process Groups Monitoring & Controlling Processes Planning Processes Enter Phase / Start Project Initiating Processes Closing Processes Exit Phase / End Project Executing Processes

148 Project Life Cycle Theory A collection of project phases. Usually following in sequence. Sometimes overlapping. The names and numbers are determined by: The management and control needs of the organisation or organisations involved in the project (i.e. the unique aspects of the organisation). The nature of the project itself. The area of application. The technology and/or industry engaged in the project. Can be documented with a methodology. Provides basic framework for managing the project. Characteristics: See slides.

149 Project Life Cycle Theory Continued Product vs Project Life Cycle Relationships: Product life cycle: Collection of product phases. Usually following in sequence. Never overlaps. Determined by: Manufacturing and control needs of the organisation. Last phase is the product s retirement phase. Expected result of a project is related to a product: Development of a new product this becomes a project. Adding new functions or features to a product this becomes a project. Develop a new model of the product this becomes a project. If all projects related to one product are overseen by a higher authority it could increase likelihood of success.

150 Project Life Cycle Theory Continued Project Phases: Divisions within a project where extra control is needed. To effectively manage the completion of a major deliverable. Element of the project life cycle. Not a project management process group. Characteristics: Close of a phase ends with some transfer or handoff of the work product produced as the phase deliverable. The work has a distinct focus that differs from any other phase. The primary deliverable or objective of the phase requires an extra degree of control to be successfully achieved. Differ in duration or length.

151 Project Life Cycle Theory Continued Project governance across the life cycle: Provides a comprehensive, consistent method to control the project and ensure its success. Phase structure provides formal basis for control. A phase is formally closed off with a review of the deliverables to determine completeness and acceptance. Closing off of one phase does not include automatic authorisation for the next phase. Phase-to-phase relationships: Sequential relationship. Overlapping relationship. Iterative relationship. Projects vs. operational work: Shared characteristics: Performed by individuals. Limited by constraints, including resource constraints. Planned, executed, monitored and controlled. Performed to achieve organisational objectives or strategic plans.

152 Project Life Cycle Theory Continued Operations: Are on-going. Produce repetitive products, services or results. Sustains the organisation over time. Does not terminate when the current objectives are met. Operations department interacts with the project team to achieve project goals. Examples of when project deliverables are integrated into the future business practices of the operations department: Developing a new product or service that is added to an organisation s product line to be marketed and sold. Installing products or services that will require on-going support. Internal projects that will affect the structure, staffing levels or culture of an organisation. Developing, acquiring and enhancing an operational department s information system.

153 Project Life Cycle Theory Continued Stakeholders: Persons of organisations (customers, sponsors, the performing organisation, the public) who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project. May also influence the project, deliverables, project team members. Project team must identify both internal and external stakeholders. Project manager must manage the influence of various stakeholders. Table: Organisational Influences on Projects. Project Characteristics Project Manager s Authority Resource Availability Who controls the project budget Organisation Structure Functional Matrix Weak Balanced Strong Little or None Little or None Functional Manager Limited Limited Functional Manager Low to Moderate Low to Moderate Mixed Moderate to High Moderate to High Project Manager Projectized High to Almost Total High to Almost Total Project Manager Project Manager s Role Part-Time Part-Time Full-Time Full-Time Full-Time Project Management Administrative Staff Part-Time Part-Time Part-Time Full-Time Full-Time

154 Project Documents Business case. Project charter. Project plan. Project schedule. Technical specification.

155 Quality control Initial project planning Quality planning Final project management plan approval Do work Integrated change control Do work following the new plan Repeat quality assurance and quality control Quality assurance Quality Quality is improved: Processes are followed. Changes are made. Good practices are shared with the organisation. Problems are found in advance. The project management plan and project documents are updated.

156 Plan Quality Inputs, Tools & Techniques and Outputs Inputs: Scope baseline. Stakeholder register. Cost performance baseline. Schedule baseline. Risk register. Enterprise environmental factors. Organisational process assets. Tools & Techniques: Cost-benefit analysis. Cost of quality. Control charts. Benchmarking. Design of experiments. Statistical sampling. Flowcharting. Proprietary quality management methodologies. Additional quality planning tools. Outputs: Quality management plan. Quality metrics. Quality checklists. Process improvement plan. Project document updates.

157 Quality Perform quality assurance: Are we using the standards? Can we improve the standards? Quality assurance tools and techniques: Plan quality and perform quality control tools and techniques. Quality audits. Process analysis. Outputs of perform quality assurance.

158 Quality Continued Perform quality control: The process of ensuring a certain level of quality in a product or service. It looks for products or services that do not meet the standards of quality. Control means measure. Mutual exclusivity. Probability. Normal distribution. Statistical independence. Standard deviation (Sigma). 3 or 6 Sigma. Seven basic tools of quality: Cause and effect diagram. Flowchart. Histogram. Pareto chart. Run chart. Scatter diagram. Control chart.

159 Quality Continued Plan quality outputs: Quality management plan. Quality metrics. Quality checklists. Process improvement plan: Process boundaries. Process configuration. Process metrics. Targets for improved performance. Project document updates.

160 Quality Continued Quality audit: A structured, independent review to determine whether project activities comply with organisational and project policies, processes and procedures. Quality: The totality of features an inherent or assigned characteristics of a product, person, process, service and/or system that bears on its ability to show that it meets expectations or satisfies stated needs, requirements or specifications. Quality criteria: A description of the quality specification that the product must meet, and the quality measurements that will be applied by those inspecting the finished product. Quality inspection: A systematic, structured assessment of a product carried out by two or more carefully selected people (the review team) in a planned, documented and organised fashion. Quality management: The coordinated activities to direct and control an organisation with regard to quality.

161 Quality Continued Quality management strategy: A strategy defining the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during a project. Quality management system: The complete set of quality standards, procedures and responsibilities for a site or organisation. Quality records: Evidence kept to demonstrate that the required quality assurance and quality control activities have been carried out. Quality register: Contains summary details of all planned and completed quality activities.

162 Risk Risk response strategies (risk mitigation strategies): Response strategies for threats: Avoid. Mitigate. Transfer. Response strategies for opportunities: Exploit. Enhance. Share. Risk reassessment: Risk management plan and risk register must be reviewed periodically and adjusted as required. Risk audits: Arranged by project manager. Result is the identification of lessons learned for the project. This serves as evidence of how seriously risk should be taken on a project.

163 Risk Continued Risk factors: The probability that it will occur. The range of possible outcomes. Expected timing in the project life cycle. The anticipated frequency of risk events from that source. Risk averse: Someone who does not want to take risks. Risk tolerances: The areas of risk that are acceptable or unacceptable. Risk thresholds: The point at which a risk becomes unacceptable. Six sequential risk management processes: Plan risk management. Perform quantitative risk management. Identify risks. Plan risk responses. Perform qualitative risk management. Monitor and control risk responses.

164 Risk Outputs Plan risk management outputs: Risk management plan: Methodology. Roles and responsibilities. Budgeting. Timing. Risk categories. Definitions of probability and impact. Stakeholder tolerances. Reporting formats. Tracking. Risk categories: External. Internal. Technical. Unforeseeable. Causes of risks: The customer. Lack of project management effort. Lack of knowledge of project management. The customer s customers. Suppliers. Resistance to change. Cultural differences. Sources of risks: Schedule. Cost. Quality. Scope. Resources. Customer/stakeholder satisfaction.

165 Risk Outputs Continued Types of risk: Business risk. Pure (insurable) risk. Identify risks: Documentation reviews. Information gathering techniques: Brainstorming. Delphi technique. Interviewing. Root cause analysis. SWOT analysis: Strengths. Weaknesses. Opportunities. Threats. Checklist analysis. Assumptions analysis. Diagramming techniques. Risk register: List of risks. List of potential responses. Root cause of risks. Updated risk categories.

166 Risk Response Plan Risk responses: Do something to eliminate the threats before they happen. Do something to make sure the opportunities happen. Decrease the probability and/or impact of threats or increase the probability and/or impact of opportunities. For the remaining threats that cannot be eliminated: Do something if the risk happens (contingency plans). Do something if contingency plans are not effective (fall back plans). Outputs of Plan Risk Responses: Project management plan updates. Project document updates. Risk register updates: Residual risks. Contingency plans. Risk response owners. Secondary risks. Risk triggers. Contracts. Fall back plans. Reserves (contingency).

167 Risk Continued Outputs of monitor and control risks: Risk register updates. Change requests. Project management plan updates. Project document updates. Organisational process assets updates. Risk categorisation: What will we find if we regroup the risks by categories? What will we find if we regroup the risks by work packages? Risk urgency assessment: Qualitative risk analysis includes noting risks that should move more quickly through the process than others.

168 Time (Duration) Time: Plus or minus an amount of time on the target completion dates. Timescale: Corporate and/or programme management will wish to know: Over what period the project costs will be incurred. Over what period the cost/benefits analysis will be based. When the organisation can expect to accrue benefits. What the earliest/latest feasible start date is. What the earliest/latest feasible completion date is.

169 Scope Scope baseline: The agreed-upon project scope statement, work breakdown structure and work breakdown structure dictionary. Verify scope: This process involves frequent, planned-in meetings with the customer or sponsor to gain formal acceptance of deliverables during monitoring and control. Control scope: Involves measuring project & product scope performance & managing scope baseline changes. Scope: For a plan, the sum total of its products and the extent of their requirements. Described by the product breakdown structure for the plan and associated product descriptions. Scope tolerance: The permissible deviation in a plan s scope that is allowed before the deviation needs to be escalated to the next level of management. Documented in the respective plan in the form of a note or reference to the product breakdown structure for that plan.

170 What Is Scope? Scope is the what : Technical specification. Risks. Quality. Time (Hours) Control & measure during the project: Time (hours). Duration (start & end). Cost (amount). Cost (Amount) Scope (what): Technical specifications and others: Architectural. Design diagrams. Risk. Quality. Scope (What)

171 Control Scope Inputs, Tools & Techniques and Outputs Inputs: Project management plan. Work performance information. Requirements documentation. Requirements traceability matrix. Organisational process assets. Tools & Techniques: Variance analysis. Outputs: Work performance measurements. Organisational process assets updates. Change requests Project management plan updates. Project document updates.

172 Stages and Phases A PRINCE2 project is planned, monitored and controlled on a stage-to-stage basis. Management stages provide senior management with control points at major intervals throughout the project. Breaking the project into a number of stages enables the extent of senior management control over projects to be varied according to the business priority, risk and complexity involved. Planning can only be done to a level that of detail that is manageable and foreseeable. PRINCE2 requires that there be a minimum of 2 management stages: 1 initiation stage. 1 or more further management stages. Management products assisting the project manager in establishing baselines for progress control: Project plan. Stage plans. These form the basis of the day-to-day control of the stage. Exception plan.

173 Plan the next stage: Activity Summary

174 Plan the next stage: Responsibilities

175 Stages and Phases Continued Report stage end: The results of a stage should be reported back to the project board. So that progress is clearly visible to the project management team. Use of management stages: Partitions of the project with management decision points. A collection of activities and products whose delivery is managed as a unit. Management stages: Provide review and decision points. Give the ability to ensure that key decisions are made prior to the detailed work needed to implement them. Allow clarification of what the impact will be of an identified external influence. Facilitate the management by exception principle. The project board authorises one management stage of the project at a time.

176 Stages and Phases Continued Number of stages: Flexible. Depends on the scale and risk of the project. Defining management stages is a balancing act: How far ahead in the project is it sensible to plan. Where the key decision points need to be on the project. The amount of risk within a project. Too many short management stages. How confident the project board and project manager are in proceeding. Length of stages: PRINCE2 does not define. Greater risk, uncertainty or complexity = shorter stage. Depends on point within the project life cycle: The planning horizon at any point in time. The technical stages within the project. Alignment with programme activities. The level of risk.

177 Stages and Phases Continued Technical stages: Group work by set of techniques used/products created. Often overlap. Boundary of two types of stages (management and technical) will coincide often. Authorise a stage or exception plan: Stage should only start when the project board says it should. If an exception has occurred during the stage the project board may request that the project manager produces an exception plan for project board approval. Only exceptions to stage plans or project plans need to be escalated for approval. The project board may appoint project assurance to undertake some of the reviewing and assessing actions.

178 Stages and Phases Continued Plan the next stage: Stage plan for next management stage is produced when the current stage is near an end. If the next stage is the final stage, the plan should include closure activities. Project manager must consult with: Project board. Project assurance. Team managers. Other stakeholders. Recommended by PRINCE2: Review the components of the project initiation documentation. Produce the stage plan for the next stage. Create or update configuration item records for products in the next stage. Update the issue register and risk register. Update the quality register for planned quality management activities.

179 Stages and Phases Continued Review the stage status: Objective is to maintain an accurate and current picture of progress on the work being carried out and the status of resources. How frequently this happens is defined in the stage plan. Recommended by PRINCE2: Review progress for the stage. Based on the analysis, decide whether any actions are required. Revise the risk register and issue register as necessary. Update the stage plan if the aggregated assessment changes any forecasts. If ownership of any of the products is to be transferred to the customer as part of a phased handover. Consider whether to review lessons now or wait until a later review of stage status or when approaching a stage end. If the end of the current stage is near, prepare for the next phase. If the end of the final stage is near, prepare to close the project.

180 Change Control Process Need for scope change found during Control Scope Potential impact to scope found in Control Cost, Control Schedule, etc. Perform Integrated Change Control accept or reject the change Return to Control Scope to process the approved change

181 Project Charter Summery Project Name: Select the name carefully; it will be used to refer to the project for the life of the effort. Use language that people outside the project can understand. Project Description: Describe the essential elements of the project in a few paragraphs. Include information about the current situation and what will be different when the project is complete. Focus on the value of the changes to the organization. Objectives: Create a bulleted list of the most critical objectives of the project. Do not simply repeat items from the description. List critical goals and final results. Choose a size category of low, medium, or high. Provide information about the urgency and the benefits of the project, to Criticality: explain the selected rating. Consider the criticality based on the broadest view of the organization, not the narrow needs of a particular group. High Level Scope: Describe any project deliverables that are known at this stage. High Level Timeline: Indicate a rough timeline as to when you foreseen the project commencing and completing. If you have details on phases please include these here. Summary Budget: Provide some indication of estimated budget required to execute the project. These should include labour (permanent and/or temporary), hardware, software or any other fees. Risk of doing: Note any project risks to the business. These should include organisational, environmental and/or external risks. Risk of not doing: In converse are there any business risks of not doing the project. These should include organisational, environmental and/or external risks. Project Charter Approval Title Name/s Sign-Off Date Submitted By Reviewed By Project Sponsor Executive Committee Approval Feedback Include any additional notes or requirements from the Approval Committee above. E.g. There may be a need for a business case before the project can commence etc.

182 Project Plan Business case. Project schedule. Project communication. High level technical description. High level technical specification. Quality. Risks. Bill of materials (BOM). Contact list. Major milestones. Penalties. Conditions. Rules. Excluded/exclusion. SLA (service level agreements). Guarantees and warrantees. Contingency fee or percentage (%) allowed.

183 Project Plan Business Case Headings Motivation. Project objective. RACI (responsible, accountable, consulted, informed). Project major milestone dates. Pricing. Critical success factors. Current equipment. Envisaged bill of materials (BOM). Project process. To be submitted with the proposal. To be submitted and approved before onsite implementation (after order number is received). To be submitted on handover. References. Rules. Meetings. Working hours. Other areas to be covered in the proposal. Suppliers. Supplier valuation criteria. Sign-off.

184 Project Process: 43 Step Process Steps Budget approved (business motivation). Approved by centre, head office heads of department and executives. 2. Capex approved but requires further detail. What further detail is needed, why it was not approved and questions to gain clarification answered, requires further motivation should never be used, open ended. 3. Capex approved (business case/project charter). Approved by centre and relevant heads of department. 4. Identify project stakeholders. 5. Obtain Liberty governance, procedures, architecture and methodology. 6. High level design and layout. 7. Technical specification approved. Approved by centre and specialists assigned by heads of department, specifications should not be approved by executives or business unit managers but by the centre and specialists who understand the specifications. 8. Brand evaluation. 9. Product evaluation. 10. Supplier evaluation. 11. Mandate paperwork complete.

185 Project Process: 43 Step Process Steps Mandate loaded. 13. Project approved/received by procurement. 14. Tender issued. 15. Tender adjudication/choosing a supplier. 16. Order number issued to supplier. 17. Project kick-off meeting. 18. Equipment lead time, project documentation and pre-implementation meetings. 19. Detailed project plan approved. 20. Detailed bill of materials/quantities approved. 21. Detailed schematic diagram approved. 22. Detailed layouts and designs approved.

186 Project Process: 43 Step Process Steps ATP approved (acceptance test procedure). 24. Training schedule and plan approved. 25. Equipment on-site. 26. Training manual approved. 27. Administrator manual and passwords approved. 28. On-site implementation. 29. Constant monitoring of the project against detailed project plan, bill of materials, layouts and designs, specification and tender documents. 30. Constant updating of project progress, risks / issues and project changes. 31. Constant checking and ensuring the project is delivered against all criteria, keeping project on track and ensuring maximum business value is delivered. 32. Testing and training. 33. As built diagrams, layouts and schematics approved.

187 Project Process: 43 Step Process Steps Go live. 35. Hand over documentation accepted and sign-off. 36. Outstanding actions/deliverables list cleared and signed-off. 37. Final bug fixes complete and signed-off. 38. Lessons learnt submitted. 39. Project sign-off close. 40. Project audit. 41. Final payment. 42. SLA signed (service level agreement). 43. Handover to stakeholders and operations.

188 Lists/Reports Project schedule. Outstanding list/issues/problems. Risk list. Weekly report. Monthly report. Change log. Audit report. Project checklist. Documents: Business case. Project charter. Project plan. Project schedule. Technical specification. Project presentation. Project update presentation.

189 Project Indicators/robots/ colours/percentages

190 Project Methodologies/ Framework/Processes PRINCE2. PMP/PMBoK. Waterfall. SDLC. Agile. Scrum. Why different methodologies? Why the risk?

191 Driving a Project Project managers have Teeth.

192 Project Meetings Why have project meetings? What to cover in a project meeting? How long should a project meeting be? Project minutes of checklist/to do list? Meeting VS divide and conquer. Meeting VS telephone VS .

193 Appointing the Project Manager 1. Business Case. 2. Sponsor. 3. Negotiating your responsibilities. 4. Negotiate time, cost, scope, risk, quality if not correct.

194 Project Planning What is project planning? What is a WBS (work breakdown structure)? What is a project schedule? How to plan a project (make tea). Fail to Plan, Plan to Fail.

195 Project Dashboard

196 Project Progress Report IT Stabilisation Project Sharepoint Portal Reporting Requirements Requirements Information Title * Programme Manager Project Manager Project Status IT Stabilisation Project - Nelson Mandela Square Yvonne Hefer Burgher Nortje Green Report Date * Project Phase * Actual Start Date Scheduled Completion Date Summary Progress Statement * Detailed Progress Statement 01-Jul-10 Phase 2 28-Jun Nov-10 The network infrastructure and the Sandton City influences the daily operation. In some cases it seems that personal are constantly busy fighting fires. Overall Project Status Rating * Planning/Schedule Status Rating * Planning/Schedule Status Comment Financial Status Rating * Financial Status Comment Procurement/Tender Status Rating * Procurement/Tender Status Comment Quality Rating * Quality Rating Comment Major Issues/Risks Next Month Actions/Tasks The Pre-Stabilisation process has been completed and areas have been identified that the teams can start with. As part of the next stage, the Interconnect team will focus on removing the old cameras in the parking and back passages. Once this has been completed, the focus will shift to removing the old cabels from the parking areas. There where 3 major network related issues at the centre this month. The first was the replacement of a faulty switsh that caused network infrastructure failures. The second was servers that went down in the main server room that caused camera failures. And the 3rd was a Telkom error that caused a problem with the admin buildings opperations. Green Green The focus has been on Sandton City thus far. As soon as they have removed the critical cameras, will work commence at NMSQ Amber Amber rating at this stage as the parking at NSMQ might need to be upgrade as Centre Management is uncvertain if they want to upgrade the system in this year. If not, the system needs to be stabilised N/A No new Equipment required N/A Work to commence Issue: The Interconnect team has not had the oppertunity to gain access to the roofes as yet, to obtain the ceverity of the cabels in the roof. My concer is that even though SC is in a serious state, that NSMQ is not far from the same. Remove all redundant equipment, and cables. Ensure to keep the working equipment for Midlands. Gain access to the ceilings to determine what the current state of the ceilings are.

197 Priority Billable Task Task brought forward % Complete Hours Completed Planned Hours to Completion Total Hours Project Timesheet Company Name: Name: Sat Sun Mon Tue Wed Thu Fri Company Nam Name: Date: Customer Assigned By Planned Tasks Tick if applicable Time 1 7:00 - AM 2 7:30 - AM 3 8:00 - AM 4 8:30 - AM 5 9:00 - AM 6 9:30 - AM 7 10:00 - AM 8 10:30 - AM 9 11:00 - AM 10 11:30 - AM 11 12:00 - AM 12 12:30 - PM 13 1:00 - PM 14 1:30 - PM 15 2:00 - PM 16 2:30 - PM 17 3:00 - PM 18 3:30 - PM 19 4:00 - PM 20 4:30 - PM 21 5:00 - PM 22 5:30 - PM 23 6:00 - PM 24 6:30 - PM 25 7:00 - PM 26 7:30 - PM 27 8:00 - PM 28 8:30 - PM 29 9:00 - PM 30 9:30 - PM Total Hours: 10:00 - PM

198 Unplanned Unplanned Unplanned Unplanned Unplanned Unplanned Unplanned Project Detailed Timesheet Company Name: Company Na Name: Date: Saturday Sunday Monday Tuesday Wednesday Thursday Friday Think, Plan Time Task Task Task Task Task Task Task 1. Expenses fo 7:00 - AM 7:30 - AM 8:00 - AM 8:30 - AM 9:00 - AM 3. Planned ne 9:30 - AM 10:00 - AM 10:30 - AM 11:00 - AM 11:30 - AM 5. Issues / Pro 12:00 - AM 12:30 - PM 1:00 - PM 1:30 - PM 2:00 - PM 6. Value adde 2:30 - PM 3:00 - PM 3:30 - PM 4:00 - PM 4:30 - PM 8. Quality of w 5:00 - PM 5:30 - PM 6:00 - PM 6:30 - PM 7:00 - PM 10. Monthly S 7:30 - PM 8:00 - PM Week 1: 8:30 - PM Week 2: 9:00 - PM Week 3: 9:30 - PM Week 4: 10:00 - PM Week 5: Total: Total:

199 Project Timesheet Report Company Name: Name: 1. Expenses for the week: Amount 2. Deliverables achieved for the week: Date: Doing the right thing, at the right time, right the first time as efficiently as possible Think, Plan, Prioritise, Communicate (where am I heading / going to do (What, Where, Why, How)), Action, Progress Update, Assess (change direction if necessary), Deliver, Lessons Learnt, Communicate (what I have achieved / done) 3. Planned new tasks for next week: Hours 4.Time wasted for the week (hours) (stop, start, continue): 5. Issues / Problems AND Solutions Implemented 6. Value added / achieved for the business for the week: 7. Productivity for the week (Effectiveness / Efficiency / Initiative): 8. Quality of work: 9. Notes 10. Monthly Summary of hours Planned Actual Billable Non-Billable Week 1: Week 2: Week 3: Week 4: Week 5: Total: Signed by: Date: Approved by: Date:

200 Project Marketing Why market your project? When to market your project. Who to market to. How to market your project. Change management. Project communication.

201 Project Audit Checklist

202 Project Audit Checklist

203 Project Audit Checklist

204 Project Audit Checklist

205 Project System / Software What is project software? What is portfolio software? Software systems: MS Project. EPM. Sciforma. Delivery Pipeline (Cloud/Internet based). What is project collaboration or project workspace?

206 Project Workspace

207 Project Workspace

208 Project Timesheet

209 Project Schedule

210 Project Schedule