eee65370640c1eb2ab2191998cea0152.ppt
- Количество слайдов: 26
Rescue My Project™ Methodology for Troubled Projects Brian H. Munroe, PMP Regina, Saskatchewan September 10, 2009
Project Life Cycle Overview PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 2
My Projects Never Fail. . . DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc. PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 3
You Are Not Alone • • Any project can fail No project goes to outright failure overnight Limited window of opportunity First reactions are always denial Tendency towards invoking rash actions Root cause is never a quick find Even a termination requires some level of planning PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 4
Some Notable Failures • • • The IRS project on taxpayer compliance took over a decade to complete and cost the country an unanticipated $50 bn. The Oregon DMV conversion to new software took eight years to complete, the budget grew by 146% ($123 m) and public outcry eventually killed the entire project. In September 2006 Department of Homeland Security admitted project failure and closed the Emerge 2 program $229 m (a new financial IT system). In May 2006 the disastrous Seasprite helicopter program for the Australian Navy, with $1 bn spent, the helicopters were grounded due to software problems. In April 2005 inter-departmental warfare played a significant role in the failure of a $64 m federal IT project. In 2005 British food retailer J Sainsbury had to write off $526 m it had invested in an automated supplychain management system. In 2005 US Justice Department Inspector General report stated $170 m FBI Virtual Case File project was a failure, after five years and $104 m in expenditures. Over one 18 -month period, the FBI gave its contractor nearly 400 requirements changes. July 2004 a new government welfare management system in Canada costing $200 m was unable to handle a simple benefits rate increase. The contract allowed for 6 weeks of acceptance testing and never tested the ability to handle a rate increase. In 2004 Avis cancelled an ERP system after $54. 5 m is spent PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 5
Project Pressures Not enough MONEY DEMANDS!! Not enough PEOPLE Not enough TIME PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 6
Failure Categories • • Poor requirements definitions Poor scope management Lack of organizational support Stakeholder misalignment Inadequate risk management Communications problems Inadequate resources Inadequate project management methods PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 7
Standish Group, Chaos Study Most Common Causes of Project Failure PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 8
Cost of Changes PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 9
Symptoms of Trouble • No one organization has the same definition of “troubled” • Symptoms should act as alerts of deeper problems • Symptoms are manifestation of problems; they are not necessarily the problem itself • Trends in time, cost, scope variations have exceeded acceptable tolerance levels PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 10
Symptom Examples • • • Low team morale Consistently missing milestones Incomplete documentation High defect rate Unresolved issues; lack of corrective actions Changing requirements Stakeholder loss of interest/participation Unreported problems Defensive attitudes; lack of trust Unhealthy team conflicts PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 11
Triple Constraint If significant change to the triple constraint is required, this should be a red flag that trouble is afoot. For example: Significantly more time required to meet scope Significantly more money needed to satisfy quality Need to significantly reduce quality to meet time and cost targets Ti m e st Co Quality Scope PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 12
Trigger Event • Always be a trigger event that declares trouble • More than just another symptom; it is the final straw • No one definition of the trigger event; highly dependent on the organization and the project PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 13
Trigger Event Examples • Quantitative: – – – 30% over estimated budget 30% behind schedule Reduction in quality is required Completion date cannot be estimated Excessive overtime is being worked • Qualitative: – – – Clients completely dissatisfied, even threatening legal action Requirements are continually changing Dysfunctional communication exists Team morale is negatively impacting performance Seemingly irresolvable conflict exists PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 14
Cost Example Budget Vs. Actual Budgeted Cost Actual Expenditure Budget Overrun PMISSC Monthly Meeting Overrun Tolerance Rescue My Project - MTI Learning Inc. Copyright 2009 15
Impediments to Declaring Trouble • Sometimes called “Suppression Factors” • Hide true project status and prevent timely identification of a situation needing correction • Examples: – Denial – Fear of being blamed – Apathy – Strong incentives to deliver the project at all costs PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 16
Risk vs. Trouble Risk An uncertain event or condition that, if it occurs, has a positive or negative effect Trouble A certain event or condition that has either already occurred or will inevitably occur RISK ≠ TROUBLE PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 17
Flagging Potential Problem Areas PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 18
Project Rescue Process PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 19
Possible Rescue Outcomes 1. Project is completed successfully within original tolerances for time, cost, scope, and quality. 2. Time and cost estimates and/or project scope definitions are re-evaluated and redefined. Solutions to root causes implemented, project continues with new baselines. 3. Project is gracefully terminated. PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 20
Recovery Plan Considerations Recovery Strategy Stabilize Requirements PM Methodology And Process Change Management System Communication Plan Product/Service Plan PMISSC Monthly Meeting Resource Plan Rescue My Project - MTI Learning Inc. Copyright 2009 Metrics 21
Recovery Strategies • • • Clearly explain the recovery strategies Document mandatory requirements (Re)define requirements Address strategy for stabilizing requirements Provide clear details of what changes need to be made on the original project to realize these strategies and satisfy mandatory criteria Stable requirements are a key success criteria! PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 22
6 Rules for Great Requirements 1. 2. 3. 4. 5. 6. Correct Feasible Necessary Unambiguous Verifiable Prioritized PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 23
Role of the Rescue PM Superhero Fire-Fighter Politician Investigator PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 Manager 24
“Big Shoulders – Big Brain” When a project is in crisis and stress levels and expectations are high, tough skin and big shoulders are required. PMISSC Monthly Meeting Cool heads will prevail. So will following a well defined, structured process and using a variety of tools and templates. Rescue My Project - MTI Learning Inc. Copyright 2009 25
Thank You! Brian H. Munroe, PMP Email: bmunroe@mtilearning. com Mobile: 1 -613 -799 -3585 Training: www. mtilearning. com Project Rescue Consulting: www. rescuemyproject. com PMISSC Monthly Meeting Rescue My Project - MTI Learning Inc. Copyright 2009 26
eee65370640c1eb2ab2191998cea0152.ppt