MGMT631 Slides Five.ppt


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Like swan or duck, well-run project appears smooth and serene on top, but the project team are paddling like hell to keep afloat underneath.
  • Like swan or duck, well-run project appears smooth and serene on top, but the project team are paddling like hell to keep afloat underneath.
  • MGMT631 Slides Five.ppt

    1. 1. MGMT631 IS Project Management Slides Five
    2. 2. Session Objectives <ul><li>Projects result in change </li></ul><ul><ul><li>BPR </li></ul></ul><ul><li>And projects themselves </li></ul><ul><ul><li>are subject to rampant change </li></ul></ul><ul><ul><li>especially IT projects </li></ul></ul><ul><li>Hence Change Control </li></ul><ul><li>And Projects are inherently risk-prone </li></ul><ul><li>Hence Risk Management </li></ul>
    3. 3. Change Resistance <ul><li>Tradition & culture resist change </li></ul><ul><ul><li>only 16 % Promethean </li></ul></ul><ul><ul><li>If it ain ’ t broke, don ’ t fix it </li></ul></ul><ul><li>But in revolutionary times, traditionalists crushed beneath tidal wave of change </li></ul><ul><li>Innovation often comes from outside </li></ul>
    4. 4. Developing Pro-Change Mindset <ul><li>Through education & training </li></ul><ul><li>Upside-down thinking </li></ul><ul><ul><li>thrive in turbulent times </li></ul></ul><ul><li>Think multiple customers & stakeholders </li></ul><ul><ul><li>not just one or a few </li></ul></ul><ul><li>Use crises to change traditional attitudes </li></ul><ul><ul><li>focus on new ways to do things </li></ul></ul>
    5. 5. Constant change is a major frustation to project staff And inside projects
    6. 6. Embracing & Managing Change <ul><li>Change will happen </li></ul><ul><li>Are we prepared to deal with it? </li></ul><ul><ul><li>blurred visions </li></ul></ul><ul><ul><li>rubber baselines </li></ul></ul><ul><ul><li>fluctuating priorities </li></ul></ul><ul><li>All contribute to: </li></ul><ul><ul><li>Scope creep </li></ul></ul><ul><ul><li>schedule slippages </li></ul></ul><ul><ul><li>cost overruns </li></ul></ul><ul><ul><li>customer dissatisfaction </li></ul></ul>
    7. 7. Embracing & Managing Change (Cont.) <ul><li>As project managers, team members </li></ul><ul><ul><li>We must learn how/when to </li></ul></ul><ul><ul><li>“ Go with the flow ” </li></ul></ul><ul><ul><li>And when to resist change </li></ul></ul><ul><li>In other words we must pro-actively Manage Change </li></ul>
    8. 8. Sources of Change <ul><li>C hanging players </li></ul><ul><li>Folks change their minds </li></ul><ul><li>Budget instability </li></ul><ul><li>Technology keeps changing </li></ul><ul><li>Changing competitive environment </li></ul><ul><li>The economy </li></ul>The longer the project timeframe the more likely change will happen
    9. 9. Configuration Management (CM) <ul><li>Resist change via bureaucracy </li></ul><ul><li>Change control via CM </li></ul><ul><ul><li>Rigorously screen changes </li></ul></ul><ul><ul><ul><li>formal process for assessing merit </li></ul></ul></ul><ul><ul><ul><li>major or minor impact? </li></ul></ul></ul><ul><ul><ul><li>if major, goes to Change Control Board (CCB) </li></ul></ul></ul><ul><ul><li>document changes </li></ul></ul><ul><ul><li>update baseline </li></ul></ul>
    10. 10. Change Control Process Written change proposal CCB Review Rework proposal proposal designed, documented, implementation schedule CCB reviews Proposal implemented Rework proposal stop Written change proposal stop Rework Rejected Rework Rejected Accepted in product Accepted for impact study
    11. 11. Change Management (Harris) <ul><li>Accept all written change proposals </li></ul><ul><li>Project team assesses impact </li></ul><ul><ul><li>cost, staff, schedule </li></ul></ul><ul><li>Change team* reviews </li></ul><ul><ul><li>value, importance (politically weighted) </li></ul></ul><ul><ul><li>triage </li></ul></ul><ul><ul><li>add to scope, phase II, phase III </li></ul></ul><ul><li>* Key stakeholders, project manager </li></ul>
    12. 12. Changes: Key Questions <ul><li>For any/every change: </li></ul><ul><ul><li>There is a price to be paid </li></ul></ul><ul><ul><li>Do stakeholders understand the price? </li></ul></ul><ul><ul><li>Are they willing to pay the price? </li></ul></ul>
    13. 13. Scope Creep <ul><li>Scope Creep: frequently used term in PM </li></ul><ul><li>Minor refinements eventually build into major scope changes </li></ul><ul><li>Creep: anything beyond original project scope </li></ul><ul><li>Creep common especially in early phases of project </li></ul>
    14. 14. Scope Change Control <ul><li>Concerns </li></ul><ul><ul><li>Scope grope </li></ul></ul><ul><ul><ul><li>Inability of project team to define scope </li></ul></ul></ul><ul><ul><li>Scope creep </li></ul></ul><ul><ul><ul><li>“ Increasing featurism” </li></ul></ul></ul><ul><ul><li>Scope leap </li></ul></ul><ul><ul><ul><li>Major changes in scope </li></ul></ul></ul>
    15. 15. Myths of Scope Management <ul><li>User involvement will result in an IS project grounded in the realities of business needs </li></ul><ul><li>A scope statement will clearly define what a project will do </li></ul><ul><li>Once the scope of the project is defined, hold firm because any deviation from the original plan is a sign that the project is out of control </li></ul>
    16. 16. Myths (Cont.) <ul><li>Function of a scope change committee is to arbitrate user requests for additional features or functionality beyond the original project charter </li></ul><ul><li>Regular & frequent meetings with senior management will ensure they are kept up to date & will result in goodwill and support </li></ul><ul><li>You can always make up schedules & budgets later on if they slip a little bit </li></ul>
    17. 17. Scope Change Request Form
    18. 18. Risk – Risk – Risk <ul><li>Life is full of uncertainty, i.e. Risk </li></ul><ul><li>Projects are inherently & especially risk prone </li></ul><ul><li>Insurance companies are risk managers </li></ul><ul><li>Re projects: Murphy was an optimist </li></ul><ul><ul><li>if it can go wrong, it will </li></ul></ul>
    19. 19. Risk <ul><li>As project managers: </li></ul><ul><ul><li>We must apply systematic risk management techniques throughout project </li></ul></ul><ul><ul><li>They are part of our toolkit (PMBOK) </li></ul></ul>
    20. 20. Risk Management <ul><li>Software Engineering Institute (SEI) perspective: </li></ul><ul><ul><li>URLs  </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>Risk management must be continuous thru life of project </li></ul></ul><ul><ul><li>Risk & opportunity go hand in hand </li></ul></ul>
    21. 21. Project Management Maturity by Industry Group and Knowledge Area
    22. 22. SEI on Risk <ul><li>&quot; Risk in itself is not bad; risk is essential to progress, and failure is often a key part of learning. But we must learn to balance the possible negative consequences of risk against the potential benefits of its associated opportunity.&quot; </li></ul>
    23. 23. SEI: What is Risk Management? <ul><li>A practice with processes, methods & tools for managing risk in projects, providing a disciplined environment for pro-active decision making: </li></ul><ul><ul><li>continuously assess what could go wrong </li></ul></ul><ul><ul><li>determine which risks are most important </li></ul></ul><ul><ul><li>implement strategies to deal with these risks </li></ul></ul>
    24. 24. SEI’s Risk Management Paradigm
    25. 25. Sources of Project Risk <ul><li>environmental (largely uncontrollable) </li></ul><ul><ul><li>external, e.g. government regulations </li></ul></ul><ul><ul><li>internal, e.g. new division VP </li></ul></ul><ul><li>technical </li></ul><ul><li>market </li></ul><ul><li>financial </li></ul><ul><li>people </li></ul>
    26. 26. Sources of Project Risk (cont.) <ul><li>What goes wrong with projects in your environment? </li></ul><ul><li>Standish top five success factors </li></ul><ul><ul><li>user involvement, management support, requirements agreed/understood, planning, realistic expectations </li></ul></ul><ul><li>Verzuh top five </li></ul><ul><ul><li>agreed goals, planning, communication, controlled scope, management support </li></ul></ul>
    27. 27. Verzuh on Risk Management <ul><li>Selecting right project is business risk </li></ul><ul><li>Managing uncertainty is project risk </li></ul><ul><li>Identifying risks – involve stakeholders </li></ul><ul><li>Risk Profiles: questionnaire addressing expected project risk areas </li></ul><ul><ul><li>Guidelines: </li></ul></ul><ul><ul><li>industry & organization specific </li></ul></ul><ul><ul><li>address both product & mgt risks </li></ul></ul><ul><ul><li>gauge magnitude of risk – high/medium/low </li></ul></ul>
    28. 28. Verzuh on Risk Management All Project Management is Risk Management
    29. 29. Verzuh: Dealing with Risk <ul><li>Make a decision: </li></ul><ul><li>Accept </li></ul><ul><ul><li>understanding risks, consequences, probabilities, react if happens </li></ul></ul><ul><li>Avoid </li></ul><ul><ul><li>change scope to avoid, accept “low risk– low return” </li></ul></ul><ul><li>Monitor & have contingency plans ready </li></ul><ul><ul><li>e.g. at DIA have lower tech alternative for baggage </li></ul></ul><ul><li>Transfer </li></ul><ul><ul><li>contract, outsource, insure (but remember win—win) </li></ul></ul><ul><li>Mitigate </li></ul><ul><ul><li>work hard to reduce risk </li></ul></ul>
    30. 30. Project Risk <ul><li>Project Risk has two components: </li></ul><ul><ul><li>The probability (or likelihood) of failing to achieve a particular outcome </li></ul></ul><ul><ul><li>The consequence (or impact) of failing to achieve that outcome </li></ul></ul>Risk = function (probability, consequence)
    31. 31. Risk Management & Probability <ul><li>Probability x Impact of Risk (consequence) </li></ul><ul><li>= Expected Value (Cost) </li></ul><ul><li>Calculate expected cost of risk </li></ul><ul><li>Decision on $ to spend to reduce risk </li></ul>Verzuh
    32. 32. Qualitative Scoring of Risk The Risk Scoring Matrix
    33. 33. Probability & Consequence <ul><li>Probability or consequence of a risk condition is not, by itself, a good measure of risk </li></ul><ul><li>Which illustration depicts the higher risk? </li></ul>Consequence = Probability = Risk = High Low Consequence = Probability = Risk = Low Medium Medium Low
    34. 34. Top 10 Risk Item Tracking <ul><li>Tool for maintaining awareness of risk throughout life of a project </li></ul><ul><li>Establish periodic review of the 10 project risk items </li></ul><ul><li>List current/previous ranking, number of times the risk appears on list over time, summary of progress made in resolving each risk item </li></ul>
    35. 35. Fall 2009 Top 10 Risk Item Tracking Example
    36. 36. Expert Judgment <ul><li>Many organizations rely on the intuitive feelings & past experience of experts to help identify potential project risks </li></ul><ul><li>Experts can categorize risks as high, medium, or low with or without more sophisticated techniques </li></ul>
    37. 37. FMEA: a risk assessment tool <ul><li>Failure modes & effects analysis </li></ul><ul><li>methodology for analyzing potential reliability problems during development </li></ul><ul><li>Performed by cross functional team </li></ul><ul><li>Can greatly reduce impact of failures </li></ul><ul><ul><li>by systematically identifying, analyzing & developing corrective action plans </li></ul></ul><ul><li>Can be used multiple times thru project </li></ul><ul><li>Systematic approach: 10 steps </li></ul>
    38. 38. FEMA: 10 Steps <ul><li>Describe anticipated failure mode </li></ul><ul><li>Describe effect of failure </li></ul><ul><li>Describe causes of failure </li></ul><ul><li>Estimate severity of failure </li></ul><ul><li>Estimate probability of occurrence </li></ul><ul><li>List current controls </li></ul><ul><li>Estimate detectability of failure </li></ul><ul><li>Calculate risk priority number (RPN) </li></ul><ul><li>Recommend corrective action </li></ul><ul><li>Recalculate “predicted” RPN </li></ul>
    39. 39. Dilbert on Risk Management <ul><li>FACT: If project manager doesn’t see risk management as part of job, then risk management process will not be effective in reducing program risk. </li></ul>
    40. 40. Identifying IT Project Risks <ul><li>Brainstorming </li></ul><ul><li>SWOT Analysis </li></ul><ul><li>Cause and Effect Diagrams </li></ul><ul><li>Past Projects </li></ul>
    41. 41. SWOT Analysis
    42. 42. Cause and Effect Diagram <ul><li>Identify the risk in terms of a threat or opportunity </li></ul><ul><li>Identify the main factors that can cause the risk to occur </li></ul><ul><li>Identify detailed factors for each of the main factors </li></ul><ul><li>Continue refining the diagram until satisfied that the diagram is complete </li></ul>
    43. 43. Cause and Effect Diagram
    44. 44. Normal Distribution
    45. 45. PERT Distribution
    46. 46. PERT Distribution <ul><li>PERT distribution uses a three-point estimate where: </li></ul><ul><ul><li>a denotes an optimistic estimate </li></ul></ul><ul><ul><li>b denotes a most likely estimate </li></ul></ul><ul><ul><li>c denotes a pessimistic estimate </li></ul></ul><ul><li>PERT Mean = (a + 4m + b) / 6 </li></ul><ul><li>PERT Standard Deviation = (b - a) / 6 </li></ul>
    47. 47. Simulations <ul><li>Monte Carlo </li></ul><ul><ul><li>a technique that randomly generates specific values for a variable with a specific probability distribution. </li></ul></ul><ul><ul><li>goes through a specific number of iterations or trials and records the outcome. </li></ul></ul>
    48. 48. Risk Management Tools <ul><li>@RISK, risk analysis and simulation add-in for MS Project </li></ul><ul><li>Risk Radar®, MS Access-based project risk analysis and tracking software </li></ul><ul><ul><li> </li></ul></ul>
    49. 49. Risk Simulation Using @Risk for Microsoft Project
    50. 50. Output from Monte Carlo Simulation
    51. 51. Cumulative Probability Distribution
    52. 52. Sample Monte Carlo Simulation Results for Project Schedule
    53. 53. Risk Response Plan should include: <ul><li>The project risk </li></ul><ul><li>The trigger which flags that the risk has occurred </li></ul><ul><li>The owner of the risk (i.e., the person or group responsible for monitoring the risk and ensuring that the appropriate risk response is carried out) </li></ul><ul><li>The risk response based on one of the four basic risk strategies </li></ul>
    54. 54. Results of Good Project Risk Management <ul><li>Unlike crisis management, good project risk management often goes unnoticed </li></ul><ul><li>Well-run projects appear almost effortless, but a lot of work goes into running a project well </li></ul><ul><li>Project managers should strive to make their jobs look easy to reflect the results of well-run projects </li></ul>
    55. 55. Results (continued) <ul><li>Inherently high risk businesses use risk analysis, mitigation & avoidance tactics </li></ul><ul><ul><li>Projects finish earlier, cost less as most problems discovered & avoided/handled earlier at lower cost </li></ul></ul><ul><ul><li>Projects typically spend 1 - 2% of contract cost with a 20:1 cost avoidance/savings on investment </li></ul></ul>
    56. 56. “Waltzing with Bears” <ul><li>Practical & readable text on “Managing Risk on Software Projects” </li></ul><ul><li>Paperback </li></ul><ul><li>By Tom Demarco & Timothy Lister </li></ul><ul><li>Dorset House, 2003, ISBN 0-932633-60-9 </li></ul>
    57. 57. Manage Change & Manage Risk