SE 477 Software and Systems Project Management

SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 432 Office Hours: Tuesday, 4:00 – 5:30 SE 477: Lecture 6

Administrivia • Comments and feedback • Reminders • Journal • Team Project • Re-read the assignment • Review the Charter for deliverables: especially user survey, documentation and training; make sure you have an activity for each • Continue work on team assignment: Project Time Management • Are you on schedule? SE 477: Lecture 6

Assignment 3 SE 477: Lecture 6 Due tonight • The students need to provide at a minimum the start and completion date, duration, and effort (in staff-hours). • There should also be a summary for management. This would include a breakdown of estimates by phase and/or resource (personnel). Give enough information that an executive would not need to look at the Project file to get a good idea of the project. • Important points to note: • Holidays need to be accounted for. • Phases need to start on a new day. • Activities are all sequential (Finish to start)

Assignment 4 Assignment 4 due November 5, 2013 • Develop a risk management plan for the software development infra-structure of a project (Identify risks; estimate risk probability and impact; identify potential for risk mitigation; identify potential risk responses) • Build a Risk Register • Policies to implement • Risk audit (what to look for and what to check) • Use the risk register template for this. • You should add a summary assessment on the current state of the project vs. the ideal state and make recommendations. SE 477: Lecture 6

SE 477 – Class 6 SE 477: Lecture 6 Topic: Project Risk Management I • Risk & the Risk Management Model • Risk Management Planning • Input, tools, and output of risk management planning • Risk management plan • Risk categories • Risk Breakdown Structure (RBS) • Risk probability and impact • Risk Identification, quantification and prioritization • Where to find risks • Risk identification: tools and techniques • Assumptions analysis • Diagramming techniques • Risk identification output: the risk register

SE 477 – Class 6 • Reading: • PMP Study Guide: Chapter 6 • Kerzner: Chapter 17 • Taylor: Chapter 7 • Taylor (Survival Guide): Chapter 13 • Software Risk Management: Not Just for the Big Manufacturers? (January 1997). MD&DI (Discusses SERIM) SE 477: Lecture 6

Thought for the day No plan survives contact with the enemy. War is a matter of expedients. – Field Marshal Helmuth Karl Bernhard Graf von Moltke October 26, 1800 – April 24, 1891 SE 477: Lecture 6

Last Time SE 477: Lecture 6 Project Time Management I • Activity Resource Estimating • Activity Duration Estimating • Project Time Management II • Project Planning – Schedule Development • Scheduling • Schedule network analysis • Critical Path Method (CPM) • Forward and backward pass analysis • Calculating float • Schedule compression • Resource leveling • Schedule development output • Project Planning – Schedule Development Workflow and Example

Reality check for your project plan SE 477: Lecture 6 Testing the plan before you begin Assessing the project using risk management Involving the team in planning Building confidence for your plan Selling the plan to relevant stakeholders

Risk Management Whatever can possibly go wrong will. — Murphy’s Law Events that are extremely improbable tend to occur at the most inopportune time. [Or, The probability of an event is inversely proportional to its desirability.] — Gumperson’s Law SE 477: Lecture 6

Black Swans SE 477: Lecture 6 Risk management: There are no black swans [http://FredCohen.net/Analyst/2009-04.pdf] • The March 2011 earthquake and tsunami and crisis with the nuclear plant. • Could not happen • Sea walls were tall enough • Historical record says otherwise • Generators were ready • Assuming no tsunami could hit • BP Oil spill in April 2010 • Blow out preventer would work • Known problems • Management was on top of the problems • “Excellent record of safety”.

Black Swans SE 477: Lecture 6 • Affordable Care Act rollout of sign-up of 2013 • Cannot handle load – unable to gain access • Unable to register • Must register and sign-up before browsing option [bad requirement] • Incorrect calculations • Slow, sluggish. • No Beta test • No load testing • Late delivery • Other, state systems work.

What can Possibly Go Wrong? SE 477: Lecture 6 Consider the “average” college student: • What risks does the student encounter? How can we mitigate the damage? • Computer related: • Lose file; • Lose flash drive; • Lose hard drive; damaged • Lose computer; damaged, lost or stolen • Crash computer; corrupted files • No network? Cannot access COL • Attendance and time management • Miss class or late • Miss home work submission • Late home work submission

What can Possibly Go Wrong? SE 477: Lecture 6 Consider the “average” project: • Testing takes longer than planned – cannot resolve bugs • Vendor cannot deliver product on schedule • Critical engineer • Has accident (wipes out in ski jump) • Becomes a parent • Has major surgery • Critical engineer leaves project/company • Change of ownership. Project on hold • Major downsizing • Dysfunctional staff • Blizzard and power failures

Preface • Project Risk Managementaddresses the trade-offs between taking a risk and avoiding the negative impacts of that risk • In this class and the next, we will discuss all aspects of Project Risk Management, which spans both the Planning and Monitoring and Controlling PMI Process Groups SE 477: Lecture 6

Risk definition • According to the PMBOK Guide: • “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative impact on at least one project objective, such as time, cost, scope, or quality” • “A risk may have one or more causes and, if it occurs, one or more impacts” • Not all risks are bad:Risks can present opportunities as well as threats to a project • Risk originates in the uncertainty associated with any project – remember, projects are unique Project Risks • What can go wrong? • What is the likelihood? • What will the damage be? • What can we do about it? SE 477: Lecture 6

Elements of Risk Management Risk Identification Risk Analysis Risk Assessment Risk Risk Prioritization Management Risk Management Planning Risk Resolution Risk Control Risk Monitoring Boehm, 1991 SE 477: Lecture 6

How to Categorize Risk Risks: known, unknown, unknowable • Known Risks: Risks that can be uncovered after careful evaluation of the project plan, business and technical environment, and other reliable sources of information (I.e. unrealistic delivery dates, lack of user input etc) • Refer to those risks that can be estimated from historical information • Can be mitigated by management techniques and through response plans, should they occur • Example: Potential delay in delivery from third-party vendor • Example: Key personnel leave project • Example: Development systems down SE 477: Lecture 6

How to Categorize Risk • Predictable Risks [but unknown risks]: Risks that can be extrapolated from past projects. (Staff turnover, poor communication with the customer) • Refer to those risks that we know have a probability of occurring, but do not know the precise impact • Cannot be managed directly but can be mitigated by the use of contingency • Example: Loss of key personnel due to turnover • Unpredictable Risks“Joker” risks that are hard to predict. • Unknowable risks • Refer to those risks that are outside the scope of historical or probabilistic models for the project • Are beyond the scope of risk management and usually are addressed by crisis or disaster management • Examples: Corporate failures, natural disasters, acts of terrorism or war, major snowstorm and power loss SE 477: Lecture 6

Risk management model (after Taylor) Qualitative Risk Analysis Risk Management Planning Risk Identification Quantitative Risk Analysis Tracking & Auditing (Risk History) Evaluate & Revise Risk Control Risk Monitoring Risk Response Planning SE 477: Lecture 6

Risk Management Planning SE 477: Lecture 6

Introduction • Risk Management Planning addresses how to approach, plan, and execute all of the project risk management activities • The risk management plan is critical to the overall risk management process • Risk management plan is an input to every other risk-related process in the Planning Process Group • A well-defined, comprehensive risk management plan enhances the chances of success of the risk management process SE 477: Lecture 6

Risk management planning: tools & output • Risk management planning tools • Planning meetingsare the main tool for risk management planning • Attendees should include the project manager, members of the project management team, and stakeholders who can contribute risk-related information • Meetings will involve analysis of risk for the project, risk tolerance of the organization, and calibrating risk to the project and organization • Risk management planning output • The risk management plan is the only output from the risk management planning process • Risk management plan is detailed on following slides SE 477: Lecture 6

Risk identification input • Enterprise environmental factors • Concerned with aspects of the enterprise outside of project • One source may be enterprise historical information • Industry or academic research is another excellent source • Example: The Gartner Reports • comp.risks (Usenet discussion group/mailing list, see reading list) SE 477: Lecture 6

Input to risk management planning • Enterprise environmental factors • Most critical environmental factors are the risk tolerance levelsof the organization and the stakeholders • Risk tolerance expresses an inherent trade-off decision between benefits and cost • Stakeholders will take a risk if the benefits to be gained outweigh what could be lost • Conversely, stakeholder will avoid taking a risk because the cost or impact is too great for the amount of benefit that can be derived SE 477: Lecture 6

Input to risk management planning • Organizational process assets • Organization may already have policies and guidelines that define its risk tolerance • Project scope statement • Project assumptions, constraints, and initial defined risks in scope statement • The project scope statement contains several information sources for risk management planning: • Project deliverables • Project constraints • Project assumptions • Initial project organization • Initial defined risks • Schedule milestones SE 477: Lecture 6

Risk identification input • Risk management plan • Risk categories (e.g. as defined in RBS) are primary source of input • Budget and schedule for risk management activities • Project management plan • Project management plan contains schedule, budget, and quality plans which may be sources of risks • Risk management plan becomes an integral part of the project management plan • All other project management processes and guidelines comprising the project management plan should be considered in light of potential risks • Risk management plan should be consistent with the overall direction and management approach of the project SE 477: Lecture 6

Risk management plan content • Methodology. How risk management will be performed, including methods, tools, and sources of data • Roles and responsibilities. Team of people responsible for managing identified risks and responses, the risk ‘owners’ • Budgeting. Assign resources and estimate costs of risk management and its methods • Timing. Timing and frequency of the risk management processes • Risk categories. Develop and review during planning. Used in risk identification SE 477: Lecture 6

Risk management plan content Definitions of risk probability and impact. Discussed in detail in Qualitative Risk Analysis Probability and impact matrix. Discussed in detail in Qualitative Risk Analysis Revised stakeholder tolerances. Risk planning may result in changes in stakeholder tolerance Reporting formats. Describes the content and format of the risk register, the dictionary of risks for project Tracking. Describes how the risk activity history will be documented and how risk processes will be audited SE 477: Lecture 6

Risk categories • Risk categories are identified during risk management planning • Risk categories systematically classify risks and provide a context for understanding those risks • Used in successor process, Risk Identification • Starting point list of risk categories: • Technical, quality, or performance risks • Project management risks • Organizational risks • External risks SE 477: Lecture 6

Risk categories • Technical/quality/performance risks • Unproven or complex technology • Changes to technology anticipated during the course of the project • Unrealistic quality goals • Unrealistic performance goals • Project management risks • Improper schedule and resource planning • Poor project planning • Improper or poor project management disciplines or methodologies SE 477: Lecture 6

Risk categories • Organizational risks • Resource conflicts due to multiple projects occurring at the same time in the organization • Unrealistic scope, time, and cost objectives with respect to the organization’s resources or structure • Lack of funding for the project or diversion of funds from the project to other projects • Management oversight changes • Loss of project ‘champion’ • Project ‘politics’ SE 477: Lecture 6

Risk categories • External risks • New laws or regulations • Example: Sarbanes-Oxley Act of 2002 (corporate governance and financial practice) – “Compliance should be planned and implemented as a normal project” • Labor issues • Weather • Changes in ownership • Changes in foreign policy for projects performed (all or in part) in other countries • Catastrophic risks (force majeure) are outside the scope of risk management planning – require disaster recovery techniques • Examples: Earthquakes, meteorites, volcanoes, hurricanes, floods, civil unrest, terrorism, etc. SE 477: Lecture 6

Risk Breakdown Structure (RBS) Project Technical Project Management Organizational External Unproven Technology Schedule Planning Project Schedules Laws & Regulations Technology Changes Resource Planning Unrealistic Objectives Weather Complex Technology Project Disciplines Lack of Funding Labor Issues Quality Cost Estimates Management Catastrophic Risk Performance Budgets • Risk categories can be represented visually in a Risk Breakdown Structure (RBS) diagram • Provides hierarchical decomposition of risk categories • Analogous to WBS After Heldman et al., PMP:Project Management Professional Study Guide SE 477: Lecture 6

Defining risk probability and impact Probability is the potential for the risk event to occur during the course of the project ( 0 ≤ p ≤ 1) Impact describes the consequences to the project should the risk event occur May use subjective (high-medium-low) rating or quantitative (numeric) values We will look at probability and impact definitions in the Qualitative Risk Analysis process, where they are used SE 477: Lecture 6

Probability and impact matrix SE 477: Lecture 6 • Defines a combination of risk probability and risk impact that helps determine which risks need detailed risk response plans • Example: A risk with a high probability of occurring and a high impact will be a strong candidate for a risk response plan • Matrix is typically defined by the organization • If organization does not define a matrix, develop one during planning meetings and analysis • We will look at the probability and impact matrix in the Qualitative Risk Analysis process, where it is used

Risk Identification SE 477: Lecture 6

Introduction • Risk identificationis concerned with determining what risks might have an impact on the project • In addition, risk identification seeks to profile risks so that effective mitigation and response planning might be possible • Risk identification is an iterative and incremental process that continually adds new risks, deletes non-risks, and refines existing risk profiles as the project progresses SE 477: Lecture 6

Where risks are found Budgets/funding Schedules Scope or requirements changes Project plan Project management processes Technical issues Personnel issues Hardware Contracts Political concerns Business risk Legal risk Environmental risk SE 477: Lecture 6

Three Types of Software Risk Project RisksThreaten the project plan. I.e. if the risks materialize, then it is likely that the project schedule will slip and costs will increase. • Budgetary/funding • Schedule • Personnel issues • Resources • Project plan • Project management processes • Customers • Requirements problems – Scope or requirements changes • Project complexity and size. • Hardware • Environmental risk SE 477: Lecture 6

Three Types of Software Risk Technical RisksThreaten the quality and timeliness of the software to be produced. • Design • Implementation • Interfacing • Verification • Cutover • Maintenance • Security SE 477: Lecture 6

Three Types of Software Risk Business RisksThreaten the viability of the product to be built. • Building a great product that no-one wants anymore. (Market risk) • Building a product that no longer fits into the overall business strategy for the company (Strategic risk). • Building a product that the sales force doesn’t understand how to sell. • Losing the support of senior management due to a change in focus or a change in people. (Management risk). • Losing budgetary or personnel commitment (Budget risk) • Contracts • Political concerns • Legal risk SE 477: Lecture 6

Risk identification: tools and techniques • Documentation reviews • Effectively, a thorough review of all the inputs to the risk identification process • Information-gathering techniques • Brainstorming • With right participants and proper facilitation, brainstorming is a self-regenerating process • Delphi technique • Employs a facilitator who distributes a questionnaire to participants and who compiles and synthesizes results • Participants do not interact directly as they do in brainstorming SE 477: Lecture 6

Risk identification: tools and techniques • Interviews • Uses standard question and answer techniques with various stakeholders or anyone with project-relevant knowledge • Root cause techniques • Involves deep analysis of identified risks in order to root out other potential risks • Checklist analysis • Based on historical information and previous project team experience – requires one or more similar projects • Risks can be compiled into a checklist • Lowest level of the RBS can be used as a starting point for a checklist • Checklists for projects cannot ever be exhaustive (remember, projects are unique) SE 477: Lecture 6

Risk identification: tools and techniques • Assumptions analysis • Validates the assumptions identified and documented throughout the project planning processes • Assumptions should be accurate, complete, and consistent • Assumptions are tested against two factors: • Strength or validity of the assumption • Consequences to the project if assumption turns out to be false • False assumptions should be reclassified as risks • Diagramming techniques • Cause-and-effect (fishbone or Ishikawa) diagrams • System or process flowcharts • Influence diagrams SE 477: Lecture 6

Risk Identification Techniques • Identification based on past experience. • Identification based on historical data, perhaps through the use of a project database. • Decision Driver Analysis, where the key decisions are examined for risk. The factors influencing decisions offer possible sources of risk. • Threat identification in security risks SE 477: Lecture 6

Risk Item Checklist A checklist is useful for supporting risk identification of known and predictable risks in the following subcategories: • Product size – risks associated with the overall size of the software to be built or modified. • Business impact – risks associated with constraints imposed by management or the marketplace. • Customer characteristics – risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. • Process definition – risks associated with the degree to which the software process has been defined and is followed by the development organization. • Development environment – risks associated with the availability and quality of the tools to be used to build the product. • Technology to be built – risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. • Staff size and experience – risks associated with the overall technical and project experience of the software engineers who will do the work. SE 477: Lecture 6

Product Size Risks • Project risk is directly proportional to product size. • Measure the following sizes against previous projects. If those projects were successful & results are similar, then risk is probably low. If a large negative deviation is observed then risk is HIGH. • Estimated size of the product in LOC or FP? • Degree of confidence in estimated size estimate? • Estimated size of product in number of programs, files, transactions? • Percentage deviation in size of product from average for previous products? • Number of users of the product? • Impact on system (loading) • Anticipated volatility of the requirements? • Amount of reused software? SE 477: Lecture 6

Business Impact Risks • The following items help identify generic risks associated with business impact: • Effect of product on company revenue. • Visibility to senior management. • Reasonableness of delivery deadline • Number of customers who will use the product & consistency of their needs. • Number of other products that it will interact with. • Sophistication of end users. • Governmental constraints. • Costs associated with late delivery or a defective product? SE 477: Lecture 6

Customer Related Risks • The following items help identify generic risks associated with the customer: • Have you worked with the customer in the past? • Does the customer have a solid idea of what is required? • Is the customer willing to commit significant time to the requirements gathering process? • Is the customer willing to establish rapid communication links with the developer? • Is the customer willing to participate in reviews? • Is the customer technically sophisticated in the product area? • Does the customer understand the software process? • Risks should be investigated if the answer to any of these questions is “NO”. SE 477: Lecture 6

SE 477 Software and Systems Project Management