Project Risk Log Instructions [Enter Project Name] Risk Log Instructions Purpose: The Risk Log is used by the Project Manager to record, track and manage all risks identified throughout a project. It is based upon the established Risk Management Strategy and Risk Management process. The first tab is also available as a standalone worksheet for initial risk assessment during initial project planning, which can then be pasted over the same worksheet in this Excel workbook for ongoing reference and updating. The second tab is used to plan and administer Risk Mitigation plans. The third tab facillitates periodic reporting of the project's Top Ten risks for the period ahead, and risk activity (changes) in the period just completed. Most of those changes result from changes in risks/risk factors on the first tab, or Mitigation Plan changes on the second tab. Set-Up: Copy the template to a project-specific directory (i.e., Risk Log) and rename to " Risk Log" Definition: A Risk is a potential issue or threat of such severity that it impacts the successful delivery of the project. Risks require Mitigating Plans and Contingency Plans to be developed to minimize the impact of the risk. It is the responsibility of project leadership to be constantly aware of potential threats to the project's success. These may include potential vendor issues (i.e., critical software release not being delivered on time or use of an unproven hardware or software component), resource issues (i.e., project team resources not having proper skill sets or a client not providing subject matter expertise as required), client issues (i.e., a client not signing off on a deliverable in a timely manner, causing other deliverables to be impacted or the client's business slowing down, potentially impacting their ability to continue with the project). Refer to the tab Common Sources of Project Risk for a list of common project risks. Risks are identified and managed not only initially, but also throughout the project lifecycle. The risk exposure should be recalculated as changes occur to the probability & impact of risk factors throughout the project. For example, if a project is dependent upon a piece of hardware being installed, the probability of the hardware not being installed drops to zero once it is installed, and therefore the risk exposure of this risk would re-calculate to zero; the risk has "aged off" and can be closed out. Risk Assessment Worksheet (RAW) Risk # Identify every risk with a sequential (unique) risk # for convenience. Upon the completion of initial project risk management planning, this risk ID # should not be changed. Risk Category: Select the category of risk from the drop-down box or leave blank Internal/External: Select the appropriate characteristic from the drop-down box. Risks external to the project are inherently more difficult to manage. Risk Title: Provide a short description of the Risk. This field may be used for summary reports. Impact: Assess the Impact severity as High (3), Medium (2) or Low (1). Refer to the Risk Calculation tab for estimating rules. This assessment may change as mitigation and contingency plans are developed/executed which may lessen the impact. Conversely, the impact may increase as the project nears critical milestones. Probability: Assess the Probability of the risk being realized as High (3), Medium (2) or Low (1). Refer to the Risk Calculation tab for estimating rules. Even more than the Impact assessment, the Probability may change over time (e.g., requirements/gaps uncertainty should decline to zero before UAT). $ASQProject Risk Log Template.xlsInstructions Page 1 of 33 Version 0.5Project Risk Log Instructions [Enter Project Name] Exposure: Calculate overall exposure by multiplying Impact severity x Probability of occurrence. Refer to the Risk Calculation tab for calculation & prioritization rules. This provides an overall measure of risk which translates directly into priorities, and the log should be resorted by this column during initial risk assessment (high to low). Risk Description: Provide a more detailed description of the risk, including the potential impact (AKA, Risk Statement). Identify the impacts as specifically as possible in terms of timeline delays, financial costs, audit considerations, etc. For instance, assuming a FTE per day cost of $1,600, if a vendor delays release of a software component which results in 3 developers not being able to make progress for a week, the impact would be $24,000. It is important that the impact be identified and communicated to the client in order for them to clearly understand the potential impact if a mitigating or contingency plan is not implemented. The following columns are not initially included in the "Print Area" and are not set up for printing/reporting initially. They should be updated by the Project Manager whenever applicable. Time frame: Three timeframe periods are offered in the drop-down box for the purposes as prioritizing risks; depending upon where the probability of a risk occurring is at its peak. Short term refers to risks in the current reporting period; mid-term refers to risks in the current project project phase, but not the current reporting period; Long term refers to risks during the project life cycle but not with the current phase. Risk Status: Drop-down box indicating the current status of the risk. It is on the Risk Assessment Worksheet (RAW) because it is the first sheet used, and because the risk assessment may neet to be recalculated at intervals plus whenever the risks change. Reason for Change in Status: Free form, although the most common reasons for a change in status relates to Mitigation activities. Risks may also be avoided, transferred, absorbed, or retired after the period of their likelihood has lapsed without incidence. Date of Change for Change in Status: Insert appropriate date for tracking & reporting purposes. The following columns (L+) contain attribute lists, many of which are used to populate the available choices in drop-down boxes associated with various columns. Risk Mitigation Tracking Sheet All columns not defined in this section also appear on the Risk Assessment Worksheet and are defined above. For best results do not re-key data into such common columns; instead appropriate cell references back to the Risk Assessment Worksheet. Initial Exposure: Captures the original exposure level calculated on the RAW when the risk was first assessed. When a Mitigation Plan is executed, the exposure level is recalculated (RAW, columns C and D), resulting in a new current value of exposure (i.e., "residual" exposure remaining after Mitigation). Preserving the original pre-Mitigation exposure level enables comparison to the current exposure level and aids in determining effectiveness, and additional mitigation if appropriate. To capture the original exposure, copy it to the clipboard from column C and paste it "special -values" to column D so that the data (and not the formula) is copied from C. Owner: Each Risk should be assigned a specific owner. Because of the severity and potential impacts of Risks (as compared to Issues), no one other than senior project or client leadership should be assigned responsibility for resolving Risks. Status: This field should be updated as part of the Weekly Status Reporting process. Leave blank or use the drop-down for appropriate values. $ASQProject Risk Log Template.xlsInstructions Page 2 of 33 Version 0.5Project Risk Log Instructions [Enter Project Name] Date Risk Identified: This will be the date on which risk assessment was performed for the project; exceptions will be "new" risks that were identified during the course of the project. Planned Execution Date: This is the planned completion date for the Mitigation Plan corresponding to this line item; if the mitigation plan has been incorporated into the project's WBS, it should the same as the completion date planned there. Date Executed: The Project Manager should complete this field once a Mitigation Plan has been executed. If a new Mitigation plan is warranted after "residual" risk is recalcuulated these last two columns should be documented (i.e., the Mitigation Plan document should be completed & archived) and then refreshed for the next round of Mitigation. Mitigation Plan: If not already done by the Project Manager, the Risk Owner should analyze the Risk to identify ways to mitigate or minimize the Probability of a risk occurring, or the potential negative impact if it does occur. For instance, building buffer time into the workplan to receive and test vendor components may lessen the impact of a brief delay. Or sending project team members to training will minimize the likelihood of the team being deficient in the related skills. All risks with exposures of 3 (moderate) or greater should have a mitigation plan & the plan should be executed as soon as feasible. If more than 1 line is required for defining the mitigation plan, a Risk Mitigation Plan template is available to record and track the mitigation plan as a "mini-project plan"; its filename should be put here and hyperlinked. Once a mitigation plan has been executed, the risk must be re-assessed to determine whether its risk exposure has been reduced sufficiently, or should be followed by another attempt to mitigate. Refer to the Common Mitigation Strategies tab for suggestions. Mitigation Results: Free form. The PM uses this space to document the results of the Mitigation Plan and any further action; (e.g, develop a follow-up Mitigation Plan to further reduce exposure level, accept the current exposure level, retire the risk, etc.). Contingency Plans: A Contingency Plan is different from the Mitigating Plan in that a Mitigating Plan usually attempts to minimize the probability of the Risk occurring. The Contingency Plan, alternatively, always attempts to minimize the Impact should the risk be realized. For instance, if investing in training for project team members is not possible, hiring subcontractors to execute key tasks may be an alternative solution. Identifying a potential alternative software or hardware component may be necessary to address vendor risks. Building manual processes as a workaround for a complex automated interface which may not be complete on time is an alternative approach (instead of simply delaying the project). All risks with exposures of 6 or higher (high) must have a contingency plan developed and triggers defined which are monitored by a Risk Owner. Trigger(s): Thresholds exceeded, date passed, events or other symptoms that signal that the Contingency Plan must be executed. Risk Reporting Sheet Several reports are featured on this tab. They are formatted to be printed and appended or cut and paste (special, picture, Windows metafile) to a standard project status/progress report. Top Ten Risks: All fields on this report can and should be updated by inserting a reference to the corresponding risk on the RAW (columns A-D) or the Risk Mitigation Log (column E). The Top Ten Risks can be determined by sorting the RAW by exposure (descending), internal/external (ascending) and Timeframe (descending) fields on the RAW. Risk Management Activity: Risk Mitigation: All fields on this report can and should be updated by inserting a reference to the corresponding risk on the Risk Mitigation Log. Column C may be keyed in from the Mitigation Plan document if the Risk Mitigation Log merely hyperlinks to such a document. $ASQProject Risk Log Template.xlsInstructions Page 3 of 33 Version 0.5Project Risk Log Instructions [Enter Project Name] Risks Added: This report reflects risks that have been identified and added to the Risk Management Worksheet in the period being reported. All fields are updated by inserting a reference to the corresponding risk on the RAW. Risks Changed or Retired: This report reflects changes in risk factors that have changed during the reporting period (e.g., change in probability, impact, timeframe, etc.). All fields on this report (except the merged column D+E) are updated by inserting a reference to the corresponding risk on the RAW. Column D+E may be updated from the drop-down box (source list is at J5-J13 and can be augmented by the PM). Risk Management Metrics: A basic set of risk metrics is calculated in cells C62-G77 for reporting purposes. Note that the metrics include a comparison of current metrics with those reported in the last reporting period and the change between the current and the previous period's metrics are calculated. To enable the "current period, previous period, change" calculation the PM must copy current numbers and "paste special values" to the "Prior Reporting Period" column right after status reports are generated. A normal copy and paste will result in the formulas as well as the values to be copied, resulting in both current and previous period cells pointing to the same columns. Risk Calculation Parameters This tab reflects the risk calculation parameters defined in the Risk Management Strategy, as a convenience to the PM. It is the responsibility of the PM to ensure that any differences between the parameters defined in that Strategy document and this workbook be the approved result of tailoring for this project. Common Project Risks This tab reflects the common categories and sources of project risk defined in the Project Risk Management Strategy document, which is to be considered the Master list. Ensure that this tab is reflects any updates made to that list. Add any sources to this tab that appear to be necessary and useful, and determine whether or not they should be added to the list in the Risk Management Strategy. Common Mitigation Strategies This tab reflects common mitigation strategies for common categories/sources of project risk. $ASQProject Risk Log Template.xlsInstructions Page 4 of 33 Version 0.5Risk Assessment Worksheet [Enter Project Name] Risk # Risk Category Internal /External Risk Title Impact (Scale 1-3) Probability (Scale 1-3) Exposure (F x G) Risk Description (Condition & Consequence) Timeframe Risk Status Reason for Change in Risk Status Date of Change in Risk Status 1 Dependency Internal New Technology 2 New technology will significantly lengthen project (learning curve) Short term Closed Avoided 12/6/2006 2 Technical Internal Lack of Technology Competence 3 1 3 Need 2 Modula 2 developers, none available. Possible schedule impacts. Long Term Re-Assessed Mitigated 12/23/2006 3 Business External Unreasonable Expectations 2 1 2 10% across the board budget cut can impact quality, lengthen schedule Mid-term Re-Assessed Mitigated 12/23/2006 4 Business External Inadequate User Input 2 1 2 User schedule conflicts result in unclear requirements; rework Mid-term Re-Assessed Mitigated 12/23/2006 5 Business External Changing Requirements 2 1 2 Changing requirements result in design changes and rework Long Term Re-Assessed Mitigated 12/23/2006 6 Planning External Unrealistic Timelines 2 2 4 Aggressive schedule may result in reduced quality, esp. documentation Long Term Work in Progress Workflow 12/23/2006 7 Organizational Internal Lack of Resources 2 Not enough internal resources. Possible schedule impacts. Short term Closed Mitigated 12/24/2006 8 Business External Incomplete Requirements 2 Unstated requirements result in change requests and rework Mid-term Closed Aged Off 12/23/2006 1/30/2008 D:\Docstoc\Working\ActivePDF\Input\$ASQProject Risk Log Template.xls Page 5 of 33Risk Assessment Worksheet [Enter Project Name] 1/30/2008 D:\Docstoc\Working\ActivePDF\Input\$ASQProject Risk Log Template.xls Page 6 of 33Risk Mitigation Tracking Sheet [Enter Project Name] Risk # Risk Title Exposure Initial Exposure Risk Owner Risk Status Date Risk Identified Planned Exec. Date Date Executed Mitigation Plan (Name or Title, Link) Results of Mitigation (Incl. Lessons Learned, if any) Contingency Plan (Name or Title, Link) Contingency Plan Trigger 1 New Technology 6 PM Closed 11/29/06 12/08/06 12/6/2006 Use proven technology instead Avoided risk, closed 2 Lack of Technology Competence 3 6 NASA Re-Assessed 11/29/06 12/23/06 12/23/06 Outsource to vendor with expertise -fixed price Reduced to moderate, external dependency 3 Unreasonable Expectations 2 4 Proj. Coord. Re-Assessed 11/29/06 01/15/06 1/15/2006 See Mitigation Plan Unreasonable Expectations Reduced to low, external dependency 4 Inadequate User Input 2 4 Bus. Sponsor Re-Assessed 11/29/06 12/20/06 12/20/2006 See Mitigation Plan Inadequate User Input Reduced to low, external dependency 5 Changing Requirements 2 4 Lead BA Re-Assessed 11/29/06 02/08/07 1/18/2006 User education on Chg. Mgmt., Scope Mgmt. Reduced to low, external dependency 6 Unrealistic Timelines 4 4 PM Work in Progress 11/29/06 02/18/07 See Mitigation Plan Unrealistic Timelines 7 Lack of Resources 4 PM Closed 11/29/06 12/24/06 12/24/2006 1. Resource backfills 2. Acquire consultants Mitigated, closed 1/30/2008 $ASQProject Risk Log Template.xls Risk Mitigation Tracking Sheet Page 7 of 33Risk Mitigation Tracking Sheet [Enter Project Name] Risk # Risk Title Exposure Initial Exposure Risk Owner Risk Status Date Risk Identified Planned Exec. Date Date Executed Mitigation Plan (Name or Title, Link) Results of Mitigation (Incl. Lessons Learned, if any) Contingency Plan (Name or Title, Link) Contingency Plan Trigger 1/30/2008 $ASQProject Risk Log Template.xls Risk Mitigation Tracking Sheet Page 8 of 33Risk Reporting [Enter Project Name] Risk Description (Conditions & Consequences) 6 Unrealistic Timelines Aggressive schedule may result in reduced quality, esp. documentation 4 Work in Progress Risk Description (Conditions & Consequences) 3 Unreasonable Expectations 10% across the board budget cut can impact quality, lengthen schedule 2 Re-Assessed 8 Incomplete Requirements Unstated requirements result in change requests and rework Closed Risk Management Activity for the Period Date Executed 2 Lack of Technology Competence Outsource to vendor with expertise -fixed price NASA 12/23/2006 Reduced to moderate, external dependency 3 Unreasonable Expectations See Mitigation Plan Unreasonable Expectations Proj. Coord. 1/15/2006 Reduced to low, external dependency 4 Inadequate User Input See Mitigation Plan Inadequate User Input Bus. Sponsor 12/20/2006 Reduced to low, external dependency 5 Changing Requirements User education on Chg. Mgmt., Scope Mgmt. Lead BA 1/18/2006 Reduced to low, external dependency 6 Unrealistic Timelines See Mitigation Plan Unrealistic Timelines PM 7 Lack of Resources 1. Resource backfills 2. Acquire consultants PM 12/24/2006 Mitigated, closed Risk Description (Conditions & Consequences) # Risk Title Reason for Change or Deletion Exposure New Status 1 New Technology Avoided Closed 5 Changing Requirements Mitigated 2 Re-Assessed 6 Unrealistic Timelines Workflow 4 Work in Progress 7 Lack of Resources Mitigated Closed 8 Incomplete Requirements Aged Off Closed Notes: 1 The tables above are structured for printing or cutting & pasting into a Risk Management Report. Change with discretion. 2 Insert references to other tabs, cells where appropriate rather than rekeying data for better quality control & efficiency 3 Use the Risk statistics below where appropriate. 4 Be sure to copy and paste special values from This Period to Previous Reporting Period ASAP after each reporting period External Dependencies # Risk Title Priority/Exposure Mitigation Plan Status # Risk Title Priority/Exposure Mitigation Plan Status Risks Added Risks Changed or Closed Result # Risk Title Priority/Exposure Mitigation Plan Status # Top Risks Risk Title Mitigation Steps Owner Risk Mitigation Activity 1/30/2008 $ASQProject Risk Log Template.xls Risk Reporting Page 9 of 33Risk Reporting [Enter Project Name] See cells N1:S5 for Weekly Status Report Cut & Paste DCN: PROJM_TEMPL_064_V1.0 1/30/2008 $ASQProject Risk Log Template.xls Risk Reporting Page 10 of 33Risk Reporting [Enter Project Name] 1/30/2008 $ASQProject Risk Log Template.xls Risk Reporting Page 11 of 33Risk Reporting [Enter Project Name] 1/30/2008 $ASQProject Risk Log Template.xls Risk Reporting Page 12 of 33This Period Previous Period (Week -1) Change Total Risks identified = 8 8 0 Total exposure = 13 25 -12 Avg exposure = 1.625 3.125 -1.5 *Project Risk Characterization = Low Moderate N/A Total Risks to be mitigated 7 7 0 Total Risks with Mitigation Plan developed 7 7 0 Total Mitigation Plans Executed 6 2 4 Total Mitigation Plans yet to be executed 1 5 -4 Total Contingency Plans needed 0 0 0 Total Contingency Plans developed 0 0 0 Count of Risk Factors closed this period 3 1 2 Count of Risk Factors with changes this period 5 7 -2 Deactivate Refresh button in the same way, immediately after using to prevent unintentional refreshes Risk Management Metrics To Activate Refresh button, <(right click) Properties> , (paste special values from "This Period" after each reporting period, before making updates Refresh Previous Periods Refresh Previous Periods9/21/2006 Previous Period (Week -2) Change Previous Period (Week -3) Change Previous Period (Week -4) Change 8 0 0 8 0 0 34 -9 0 34 0 0 4.25 -1.125 0 4.25 0 0 High N/A N/A N/A N/A N/A 7 0 0 7 0 0 0 7 0 0 0 0 0 2 0 0 0 0 0 5 0 0 0 0 1 -1 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 7 0 0 0 0 Management Metrics right click) Properties> , close properties, Period" after each reporting period, before making updates to risk log for "This Period")1 0 0 I mpact 3 1 0 0 0 0 Probability Current Risk Exposure0 1 0 I mpact 1 5 1 0 0 0 Probability Cut and Paste special values here a snapshot of risk exposure at the end of project planning, before risk mitigation. Original Risk ExposureProject Risk Log Risk Calculation Parameters Weighting Rules Dimension Rule Weight Probability Probability of Occurrence High -50/50 or greater 3 0 Medium -10% or greater likelihood 2 Any Low -<10% but >0% 1 1 None <0% 0 12 Severity of Impact High – Fatal – System unuseable -$M lost 3 1 Medium – Serious problems/financial harm; can survive with "workarounds" for short period 2 3 Low -Significant but "tolerable" problems/financial harm; can survive with "workarounds" for extended period 1 2 None 0 233Project Risk Log Risk Calculation Parameters Exposure Calculation Impact Exposure (prob x sev) Priority Any 0 None 0 0 None 1 1 Lowest 2 2 Low 1 2 Low 3 3 Moderate 1 3 Moderate 2 4 Moderate 3 6 High 2 6 High 3 9 HighestProject Risk Log Risk Calculation ParametersProject Risk Log Common Project Risks • Business Uncertain requirements (i.e., no agreed upon, documented common understanding) Changing requirements (esp. if change control mechanisms are inadequate) Conflicting requirements from different business units or levels, “gold plated” vs “good enough” Solution does not satisfy the intended goal Unrealistic schedule requirements or budget allocation Commitment level volatility/Organizational continuity & Sponsorship Funding or cost uncertainties/issues • Technology Unprecedented effort -estimates unavailable Infeasible design -beyond existing feasible capabilities Local maturity (experience) level with respect to the particular technology to be used Appropriateness/adequacy of development tools. Suitability & stability of development environment Consistency, adequacy & compatibility of test environments Compatibility with production environment(s) Maturity/feasibility of the technology itself (functional, reliable, supported) • Planning Complexity of the overall effort Number & complexity of inter-team interdependencies Number & complexity of conversions & interfaces Quality of existing data Critical (aggressive) dates Lean (“Best Case”) budget Lack of contingency provisions (schedule, staffing or budget) • Organizational General resource levels/availability by job role – business as well as technical team Specific Skills/Experience/Expertise level availability esp. at critical times – business and technical Availability/timing of specific training/orientation needed by project team members Quality of teamwork, cooperation, understanding between business & technical staff Continuity of stakeholders, especially key team members Inadequate communications with actual or potential customers • External Dependency Maturity/availability/dependability of external hardware/software/network resources Inadequate or uncertain vendor capability Inadequate or uncertain subcontractor capability Level of vendor/subcontractor support/responsiveness Multiple vendors/subcontractors Overlapping scope Dependence upon external resources without authority to ensure fulfillmentProject Risk Log Common Project Risks External mandates (e.g., new regulatory requirements). Disruption of continuity of operationsProject Risk Log Common Mitigation Strategies Common Project Risks ù Uncertain requirements (i.e., no agreed upon, documented common understanding) ù Changing requirements (esp. if change control mechanisms are inadequate) ù Solution does not satisfy the intended goal ù Unrealistic schedule requirements or budget allocation ù Commitment level volatility/Organizational continuity & Sponsorship ù Funding or cost uncertainties/issues · Technology ù Local maturity (experience) level with respect to the particular technology to be used ù Appropriateness/adequacy of development tools. ù Suitability & stability of development environment ù Consistency, adequacy & compatibility of test environments ù Compatibility with production environment(s) ù Maturity/feasibility of the technology itself (functional, reliable, supported) · Planning ù Complexity of the overall effort ù Number & complexity of inter-team interdependencies ù Number & complexity of conversions & interfaces ù Quality of existing data ù Critical (aggressive) dates ù Lean (“Best Case”) budget ù Lack of contingency provisions (schedule, staffing or budget) · Organizational ù General resource levels/availability by job role – business as well as technical team ù Specific Skills/Experience/Expertise level availability esp. at critical times – business and technical ù Availability/timing of specific training/orientation needed by project team members ù Quality of teamwork, cooperation, understanding between business & technical staff ù Continuity of stakeholders, especially key team members · External Dependency ù Maturity/availability/dependability of external hardware/software/network resources ù Level of vendor/subcontractor support/responsiveness ù Multiple vendors/subcontractors ù Overlapping scope ù Dependence upon external resources without authority to ensure fulfillment ù External mandates (e.g., new regulatory requirements). ù Disruption of continuity of operationsProject Risk Log Common Mitigation Strategies Common Mitigation Approaches Mutual understanding, written document, signed Effective scope change control policy/process after requirements signed Executive Steering Committee to resolve Continuity of Strong Sponsorship at executive level Project priorities based on approved business case Project prioritization, resource planning & acquisition Detailed projects plans ---> Resource skills forecasts Get it on THEIR SCHEDULE and hold them accountable Plan & incorporate into project schedule/budget Resource skils forecasts ---> training & acquisition plans Resource skills forecast, schedule & budget Assigned responsibility for development infrastructure Unity of responsibility/authority over environments Production support review & comment on test environments Break it up into manageable pieces; ensure early "quick wins" Identify interdependencies, make responsibilities clear, TRACK Establish a range of dates; push back against unreasonable dates Build contingency responses into schedule Minimize dependency upon external entities Establish formal vendor management function within PMO or above Clarify who is responsible for what, when Obtain commitment from external Risk Owner & incorporate it into formal plans, tracking & reporting Maintain a reserve capability for contingenciesSource of Risk Ideas for Risk Reduction Include provision in contract for replacement of Acceptor if scope undefined by specified Include provision for termination of contract if scope undefined by specified milestone. Inability of user to define requirements or everexpaandin scope Build prototype. Limit number of reviews of deliverables. Inaccurate or insufficient detail in requirements Build in realistic time for confirmation of requirements. Include limiting assumptions in contract. Design for information "hiding" to confine impact of likely changes and minimize their Plan incremental development, deferring changes to later increments. Changing requirements Define scope up front in measurable terms: • horizontal scope, • vertical scope (which defines the amount of functionality to be automated versus the • the limits to be applied to unbounded tasks, • other estimating assumptions, • the acceptance criteria. Ensure key opinion leaders are directly involved in the project team. Lobby for votes ahead of time to ensure that you know the outcome of key meetings before Prepare specific commitment strategies and plans to obtain political support. Establish overwhelming commitment to success at the executive level so that thoughts Set up a network to gather intelligence on what the key people are talking about -who Use change influences analysis and resistance management techniques to analyze and Political risk Assess organizational readiness: • is senior management committed to the project to ensure that it gets appropriate priority • do the management and staff perceive that this project will improve the organization • is there a champion with adequate influence who strongly supports the project, to the • are people, computer capacity, money and other resources available to implement the demands for resources that will receive higher priority? • do the staff members involved in the project have the necessary skills to implement Managing Senior Management perceptions Ensure active involvement of a Steering Committee, so that: • management rather than the project team sets the direction for the project, • the continuous, regular involvement of management generates commitment, • all issues discussed and resolved increase the user comfort factor. Maintain a record of all time spent resolving these factors. Hold regular Steering Committee meetings. Meet regularly with the Acceptor. Use decision request and change request procedures to maintain a record of all related Prepare and present expanded tables of contents and page counts as early as possible. Present samples of similar deliverables produced in accordance with the same standards. Meeting expectations (no matter how precise the terms of reference, there are typically countless questions of interpretation) Use mapping technique to organize what you know about the business organization and Obtain samples of previous work that was considered satisfactory or similar systems and Category: Sequence projects so that those with tangible benefits are completed first. Install a training infrastructure (e.g., help desk, toll-free telephone support). Achievement of projected return on investment Reduce exposure by breaking large projects into several smaller ones. User training and acceptance Set up an Implementation Advisory Group to get a broad range of users involved in acceptance Develop a training program and accompanying training plan. Specifying requirements that are difficult or impossible to meet Staff analysts who are experts in the business area and skilled at negotiating better ways Highlight user sign-offs which put emphasis on the user confirming that they understand Lack of continuity of key players Implement key personnel agreements and contractual provisions. Arrange for user involvement in analysis workshops and prototyping. Highlight user responsibility for an Acceptance Test, involving the thorough retesting Develop a plan for ensuring user understanding (e.g., user surveys). Ensure user awareness of all issues through regular status reports and sign-offs. Appoint a user co-coordinator. Set up an Implementation Advisory Group to get a broad range of users involved in acceptance Clearly define specific areas of user responsibility. Raise the visibility of dependencies at the Steering Committee. Collocate team for maximum productivity. Lack of user commitment Obtain executive commitment to provide adequate end-user participation. Add schedule management to the formal risk management plan to ensure visibility, and Minimize any changes during the project time frame which may impact the project (e.Use a more experienced team. Build an excellent infrastructure and SDE well in advance. Consider productivity tools. Minimize formal deliverables and substitute with working papers. Scrub requirements and remove unessential. Consider software reuse. Design/develop to schedule. Develop incrementally (versions). Minimize formal deliverables and substitute with working papers. Pressure for an early completion date More rigorous up-front planning. Use the WBS for time-reduction analysis. Look for Consider software reuse. Consider productivity tools. Incremental development (versions). Scrub requirements and remove unessential. Cost is too high Use Steering Committee to negotiate scope reduction. Design/develop to cost. Scrub requirements and remove unessential. Design and develop to cost. Conduct a cost/benefit analysis. Assign each function a value in an appropriate currency (time, $, m bytes of memory, Goldplating (desire to over automate) Establish a budget constraint to focus the effort on where there will be most payback avoided, including early clarification of major scope issues. With reasonable constraints, whereas without these, functionality that could be handled on an exception basis is likely cost and implementation effort to increase dramatically. Typically, even if the system Conduct scope review at start of project.Source of Risk Ensure that standards are formally documented, easily accessible, and easily understandable. Provide early feedback on adherence to standards. Uncertainty in projections or calculations Implement formal risk management techniques and risk tracking/reporting procedures. Quality of the delivered product Involve the team in defining standards in advance. Build in contractual protection. Unknown sizing data or gaps in understanding of volumetric data Implement formal risk management techniques and risk tracking/reporting procedures. "Buy information" -i.e., invest in additional data gathering. Apply capacity planning/analysis techniques (e.g., CRYSTAL, TPNS). Lack of availability of components Contingency planning. Overall system performance (end to end) Implement formal risk management techniques and risk tracking/reporting procedures. Inspections. Reference checking. Version changes in thirdpaart software over the life of the project Implement formal risk management techniques and risk tracking/reporting procedures. Shortfalls in externally (performance, stability, Benchmarking. Unknown future Design for information "hiding" to confine impact of likely changes and minimize their impact on the rest of the system. Compatibility of Build technical prototype. Build prototype. Write scenarios. Ensure that a contract is in place which clearly defines scope and deliverables. Shortfalls in the user interface User engineering: study how the user works to gain better understanding of the requirements for the user interface. Build prototype. Write user aids early. High level of end-user participation. Benchmark the "best practices" in equivalent systems elsewhere. Ideas for Risk Reduction Developing the wrong system (i.e., shortfalls in functionality) Mission analysis: study how the organization performs its mission to enable informed judgement on information requirements. User surveys. Category: Technical (Product) RiskSource of Risk Ideas for Risk Reduction Provide productivity tools. Focus on team member chemistry. Individual weekly review of days ahead/behind schedule with each team member. Weekly team meetings, as appropriate, to facilitate team communication, develop team level on a scheduled basis rather than in interrupt mode. Ensure that Project Management fundamentals have been applied (project model, visibility, Ensure that the cycle of delegate, witness commitment, and monitor commitment is adhered Increase the visibility of the Project Organization Chart (the "H" format) with the Project Committed team Ensure personal and project objectives have been reconciled. Implement formal problem resolution procedures. Problems with the Acceptor role (no Acceptor identified, inappropriate Acceptor, or multiple Acceptors) Work with the executive to identify an appropriate Acceptor. Raise the visibility of dependencies at the Steering Committee (have these routinely reviewed). Implement formal risk management techniques and risk tracking/reporting procedures. Business Unit Management Implement basic techniques such as Steering Committee, status reporting, CR, DR and Implement activity assignment and progress tracking for business responsibilities. Use overqualified Project Manager in critical situations. Ensure that resolution of all issues and problems are assigned to individuals and documented Project Management Consider nature of project in estimating amount of project management time required. Implement the Project Management techniques in the knowledge base. Requirements scrubbing. Assume risk in starting early. Incremental development. Software reuse. Design/develop to cost. Price by phase, not whole project. Use experience with sample programs (e.g., program models) to validate proposed productivity Ensure that the estimates are "owned" by the people who will be responsible to deliver Bring in special project "start-up" teams to get the team up and running. Unrealistic project plan (schedules and budget) Have independent estimators prepare detailed task-based estimates and apply sanity checks. Provide comprehensive orientation (account, proposal, objectives, application, technology, Provide additional technical training under the direction of the Technical Architect. Implement key personnel agreements for critical resources. Share resources or provide shadow/assistants to minimize the time demand on key resources Replace junior team members with more expensive but more productive staff. Consider external sources (e.g., subcontract). Personnel shortfalls (people and qualifications) Staff with top talent. Use overqualified staff in critical situations. Include adherence to standards as an item in walk-throughs. Category: Delivery External factors (e.g., strike at customer facilities) Contingency planning. Contractual protection. Uncontrolled meeting time Establish a meeting protocol ahead of time, for example: • effort will be made to limit the number of meetings and minimize the number of attendees • all scheduled meetings will require a specific agenda of matters for discussion to be • meeting duration will be stated in advance and respected, • all scheduled meetings will result in a brief summary of matters resolved and decisions Acceptance delays Use basic techniques such as Steering Committee, status reporting, CR, DR and IR procedures, Decision delays Implement basic techniques such as Steering Committee, status reporting, CR, DR and Routinely raise the visibility of business unit performance to plan at the Steering Committee Phase gaps Include in contract negotiations. Plan for early delivery and include contingency plans for if delivery is missed. Obtain authority to be responsible for the formal performance reviews of the individuals Obtain authority to be responsible for the formal performance reviews of the individuals Business ability to meet its delivery commitments Specify conditions and remedy in event of poor performance. Base payment on appropriate milestones. Use holdbacks. Subcontractor ability to deliver as planned Ensure delivery schedule is included in sub-contract. Ensure that sub-contractor's and prime contractor's delivery schedules coincide. Specify conditions and remedy in event of poor performance. Plan for early delivery and include contingency plans for if delivery is missed. Check references (and personal commitment level). Substitution clause in contract with repayment for time lost. Require Competitive Construction of Prototype. Conduct pre-award audit. Subcontractor capability Pre-qualify sub-contractors using interviews and formal assessment methodology (e.g., Conduct reference checks. New/unknown technology Consider external sources (e.g., sub-contract). Provide for training. Coach poor performers. Replace poor performers if necessary. Motivate for performance. Rotate through project roles, where appropriate, to increase team member responsibilities Include provision in contract for replacement of Acceptor if scope undefined by specified milestone. Include provision for termination of contract if scope undefined by specified milestone. Build prototype. Limit number of reviews of deliverables. Build in realistic time for confirmation of requirements. Include limiting assumptions in contract. Design for information "hiding" to confine impact of likely changes and minimize their impact on the rest of the system. Plan incremental development, deferring changes to later increments. Define scope up front in measurable terms: horizontal scope, vertical scope (which defines the amount of functionality to be automated versus the functionality to be addressed manually), the limits to be applied to unbounded tasks, other estimating assumptions, the acceptance criteria. Ensure key opinion leaders are directly involved in the project team. Lobby for votes ahead of time to ensure that you know the outcome of key meetings before you go in. Prepare specific commitment strategies and plans to obtain political support. Establish overwhelming commitment to success at the executive level so that thoughts of failure are not permitted. Set up a network to gather intelligence on what the key people are talking about -who speaks to whom, when and why, any issues that Use change influences analysis and resistance management techniques to analyze and address driving and opposing forces. Assess organizational readiness: is senior management committed to the project to ensure that it gets appropriate priority and support? do the management and staff perceive that this project will improve the organization and/or the environment in which people work? is there a champion with adequate influence who strongly supports the project, to the extent that he/she is willing to fight to have the are people, computer capacity, money and other resources available to implement the project effectively or are there other competing demands for resources that will receive higher priority? do the staff members involved in the project have the necessary skills to implement the project? Ensure active involvement of a Steering Committee, so that: management rather than the project team sets the direction for the project, the continuous, regular involvement of management generates commitment, all issues discussed and resolved increase the user comfort factor. Maintain a record of all time spent resolving these factors. Hold regular Steering Committee meetings. Meet regularly with the Acceptor. Use decision request and change request procedures to maintain a record of all related discussions and control all changes relative to the Prepare and present expanded tables of contents and page counts as early as possible. Present samples of similar deliverables produced in accordance with the same standards. Use mapping technique to organize what you know about the business organization and its key players. Obtain samples of previous work that was considered satisfactory or similar systems and use these as a benchmark to gauge expectations. RISK MANAGEMENT IDEASSequence projects so that those with tangible benefits are completed first. Install a training infrastructure (e.g., help desk, toll-free telephone support). Reduce exposure by breaking large projects into several smaller ones. Set up an Implementation Advisory Group to get a broad range of users involved in acceptance testing, training, user documentation, Develop a training program and accompanying training plan. Staff analysts who are experts in the business area and skilled at negotiating better ways of solving the business problem. Highlight user sign-offs which put emphasis on the user confirming that they understand or complaining when they don't. Implement key personnel agreements and contractual provisions. Arrange for user involvement in analysis workshops and prototyping. Highlight user responsibility for an Acceptance Test, involving the thorough retesting of all system functions. Develop a plan for ensuring user understanding (e.g., user surveys). Ensure user awareness of all issues through regular status reports and sign-offs. Appoint a user co-coordinator. Set up an Implementation Advisory Group to get a broad range of users involved in acceptance testing, training, user documentation, Clearly define specific areas of user responsibility. Raise the visibility of dependencies at the Steering Committee. Collocate team for maximum productivity. Obtain executive commitment to provide adequate end-user participation. Add schedule management to the formal risk management plan to ensure visibility, and pro-actively address schedule variances. Minimize any changes during the project time frame which may impact the project (e.g., changes to project staff, policies and Use a more experienced team. Build an excellent infrastructure and SDE well in advance. Consider productivity tools. Minimize formal deliverables and substitute with working papers. Scrub requirements and remove unessential. Consider software reuse. Design/develop to schedule. Develop incrementally (versions). Minimize formal deliverables and substitute with working papers. More rigorous up-front planning. Use the WBS for time-reduction analysis. Look for "work-ahead" items that can be started early. Consider software reuse. Consider productivity tools. Incremental development (versions). Scrub requirements and remove unessential. Use Steering Committee to negotiate scope reduction. Design/develop to cost. Scrub requirements and remove unessential. Design and develop to cost. Conduct a cost/benefit analysis. Assign each function a value in an appropriate currency (time, $, m bytes of memory, n microseconds per invocation, etc.). Establish a budget constraint to focus the effort on where there will be most payback and to force decisions that otherwise would be avoided, including early clarification of major scope issues. With reasonable constraints, a system design is apt to be spare and clean whereas without these, functionality that could be handled on an exception basis is likely to be added in to the system design causing the cost and implementation effort to increase dramatically. Typically, even if the system lives through to implementation, only a fraction of Conduct scope review at start of project.formally documented, easily accessible, and easily understandable. adherence to standards. management techniques and risk tracking/reporting procedures. defining standards in advance. management techniques and risk tracking/reporting procedures. invest in additional data gathering. analysis techniques (e.g., CRYSTAL, TPNS). management techniques and risk tracking/reporting procedures. management techniques and risk tracking/reporting procedures. hiding" to confine impact of likely changes and minimize their impact on the rest of the system. place which clearly defines scope and deliverables. how the user works to gain better understanding of the requirements for the user interface. practices" in equivalent systems elsewhere. how the organization performs its mission to enable informed judgement on information requirements. RISK MANAGEMENT IDEASProvide productivity tools. Focus on team member chemistry. Individual weekly review of days ahead/behind schedule with each team member. Weekly team meetings, as appropriate, to facilitate team communication, develop team spirit, and allow issues to be discussed at the team level on a scheduled basis rather than in interrupt mode. Ensure that Project Management fundamentals have been applied (project model, visibility, accountability and confidence). Ensure that the cycle of delegate, witness commitment, and monitor commitment is adhered to. Increase the visibility of the Project Organization Chart (the "H" format) with the Project Manager and Acceptor and make sure the Ensure personal and project objectives have been reconciled. Implement formal problem resolution procedures. Work with the executive to identify an appropriate Acceptor. Raise the visibility of dependencies at the Steering Committee (have these routinely reviewed). Implement formal risk management techniques and risk tracking/reporting procedures. Implement basic techniques such as Steering Committee, status reporting, CR, DR and IR procedures, as defined in the knowledge base. Implement activity assignment and progress tracking for business responsibilities. Use overqualified Project Manager in critical situations. Ensure that resolution of all issues and problems are assigned to individuals and documented in Decision Requests, Information Requests, Consider nature of project in estimating amount of project management time required. Implement the Project Management techniques in the knowledge base. Requirements scrubbing. Assume risk in starting early. Incremental development. Software reuse. Design/develop to cost. Price by phase, not whole project. Use experience with sample programs (e.g., program models) to validate proposed productivity rates. Ensure that the estimates are "owned" by the people who will be responsible to deliver to them. Bring in special project "start-up" teams to get the team up and running. Have independent estimators prepare detailed task-based estimates and apply sanity checks. Provide comprehensive orientation (account, proposal, objectives, application, technology, business, etc.). Provide additional technical training under the direction of the Technical Architect. Implement key personnel agreements for critical resources. Share resources or provide shadow/assistants to minimize the time demand on key resources that are also in demand for other work. Replace junior team members with more expensive but more productive staff. Consider external sources (e.g., subcontract). Staff with top talent. Use overqualified staff in critical situations. standards as an item in walk-throughs. RISK MANAGEMENT IDEASContingency planning. Contractual protection. Establish a meeting protocol ahead of time, for example: effort will be made to limit the number of meetings and minimize the number of attendees at all meetings, all scheduled meetings will require a specific agenda of matters for discussion to be prepared and distributed in advance, meeting duration will be stated in advance and respected, all scheduled meetings will result in a brief summary of matters resolved and decisions and action plans resulting. Use basic techniques such as Steering Committee, status reporting, CR, DR and IR procedures, to ensure visibility. Implement basic techniques such as Steering Committee, status reporting, CR, DR and IR procedures, to ensure visibility. Routinely raise the visibility of business unit performance to plan at the Steering Committee meeting. Include in contract negotiations. Plan for early delivery and include contingency plans for if delivery is missed. Obtain authority to be responsible for the formal performance reviews of the individuals concerned for their work on the project. Obtain authority to be responsible for the formal performance reviews of the individuals concerned for their work on the project. Specify conditions and remedy in event of poor performance. Base payment on appropriate milestones. Use holdbacks. Ensure delivery schedule is included in sub-contract. Ensure that sub-contractor's and prime contractor's delivery schedules coincide. Specify conditions and remedy in event of poor performance. Plan for early delivery and include contingency plans for if delivery is missed. Check references (and personal commitment level). Substitution clause in contract with repayment for time lost. Require Competitive Construction of Prototype. Conduct pre-award audit. Pre-qualify sub-contractors using interviews and formal assessment methodology (e.g., SEI Assessment Methodology from Carnegie Conduct reference checks. Consider external sources (e.g., sub-contract). Provide for training. Coach poor performers. Replace poor performers if necessary. Motivate for performance. Rotate through project roles, where appropriate, to increase team member responsibilities and provide career development opportunities.

Public Domain

views:809

downloads:190

rating:not rated

reviews:0

posted:1/8/2008

language:English