2. page 2 September 21, 2011 Agenda The 4 Key Project Practices “Case Studies” missing key practices A success story with a geographically distributed team Overview of some Statistics
15. page 7 September 21, 2011 Development Project Highest Priority for Division
16. page 8 September 21, 2011 Communication* Processes When? At initiation, at meetings, in hallways, emails, when ever and where ever you can Who? Project Manager to lead, all team members to participate What to do? Match the way you communicate with the circumstances (place, time, culture, etc – see follow-on slide) Always have excellent meeting preparation and follow-up Project status communicated clearly and frequently (“hard” and “soft” info) Formal presentations to review, escalate and mark phase transitions – prepare, REHEARSE, deliver! Ensure project closure (final reports, retrospectives, celebrations, thank yous, formal project acceptance) Don’t assume anything and constantly check in with team on how practices are working *This is most important process for dispersed teams after sponsorship!
42. page 10 September 21, 2011 Team Processes When? Project startup and throughout project Who? Project Manager to lead and involve team What to do? Begin team building with startup workshops and face to face meetings (especially for “new” teams!) Have and communicate a clear project objective and vision Involve all ‘leads’ in user needs assessment Create and clarify processes through team involvement and input Choose processes that work best for the greatest number. Don’t try for “perfection” Ensure proper skills on team (use skills analysis and personal knowledge of team) Allow for team growth and “stretching” of members into new areas Get personal! Get to know them and them to know each other.
43. page 11 September 21, 2011 Structured Communication needed for offshore / onshore team management
56. page 17 September 21, 2011 Managing Risk 140 risk factors assessed Risk Management plan developed Risks monitored continuously
57. page 18 September 21, 2011 Risk Analysis Summary Key Risks with High/Medium Impact Impact and How Likely are weighted as 1-High, 0.6-Medium, 0.3-Low; Risk Index = Impact * How Likely Tracking Intensity = weekly if Risk Index is high, once in 2 weeks if Medium and once in 4 weeks if Risk Index is Low
58. page 19 September 21, 2011 “Case Study of Projects” with key missing practices
59. page 20 September 21, 2011 When key practices are ‘missing’ “Case Studies” Project Sponsorship Project Planning
60. page 21 September 21, 2011 “Missing” Project Sponsorship Problem – Project Sponsorship not at right level in the correct organization. Issues: Sponsor had many competing priorities Improper staffing for project (skills, experience, total people) Little cooperation from within organization or outside stakeholders No clear user needs list created Outcomes: 2 years & $50 million spent System had few users at launch Abandoned system within a year of launch
61. page 22 September 21, 2011 Project Planning Processes not used Problem – Management not knowledgeable on project planning. Issues: No support for documenting user requirements. (just build something like “Charles Schwab” has) No understanding of value of project planning tools (eg, requirements analysis, planning, scope and priority trade-offs) Wanted a system built ‘outside’ of existing business processes. “Build it and they will come!” Outcome: 1 year and $3 million spent with no functioning system The technical team ‘abandoned’ the project for more attractive work UPSIDE: Failure of project sparked a divisional re-org that enabled a successful follow-on project. Lessons from failure informed the follow-on successful project.
62. page 23 September 21, 2011 A success story with a geographically distributed team
63. page 24 September 21, 2011 A More Successful Project A Challenging Start Causes for Success A few lessons from Success
64. page 25 September 21, 2011 A Challenging Beginning Challenges: High degree of organizational complexity (worldwide, cross divisional software development, cross functional - sales, marketing, engineering – offshore & onshore) Compressed timeline – initially a year planned from defining requirements to delivering system Team mostly new to each other Initial Scope unclear Mix of old and new technologies chosen Offshore (India) development team new to technology Business teams and development team never worked together 1st time the project manager had worked with off-shoring model New division organization No agreed upon communication and project processes, or supporting technologies
65. page 26 September 21, 2011 Why the Project Succeeded (1 of 2) Strong sponsorship and management support both vertically and horizontally Upper level management stayed involved and stepped in for key problems Project was a top division priority and one of few the sponsor had Resources (people, money, technology) assigned as project scope defined Support for Project Planning Vice-President understood the Scope, Schedule, Resource ‘triangle’ Time allowed for detailed project plans Contingency and backup plans Risk assessments created & actively managed Measured progress and re-planned based on metrics
66. page 27 September 21, 2011 Why the Project Succeeded (2 of 2) Communication Processes utilized Cognizance of time, place and with experience, cultural issues Project manager (PM) educated team mates on when and how to use various types of communications based on situation & culture PM coached team to assume nothing and to be willing to communicate any news (good or bad) quickly Team Processes implemented early Startup meeting held with people flown in for face to face Caucused team to find out what skills they wanted to contribute and improve during the project Created and constantly clarified processes with team input Built personal relationships via travel, Instant Messaging, sharing personal stories Used humor to ensure open-ness. (need to be careful in using humor in cross-cultural situations! Self-deprecation by PM worked)
67. page 28 September 21, 2011 A Few Lessons Project was a success, but still had some big lessons Short sighted in adoption of an older technology (tcl scripting language) due to internal political pressures We were on the “bleeding edge” of adopting corporate ‘standards’ Some user requirements were short-changed due to time pressures. - Caused substantial re-work later. Didn’t apply prioritization strictly enough and made some parts of application too complex for efficient operation. (tried to do something for everyone!) Not enough due diligence on other internal HP corporate divisional “partner” capabilities. - Caused substantial re-work and 6 month timeline slip.
68. page 29 September 21, 2011 Using Metrics to Manage Onshore / Offshore teams
69. page 30 September 21, 2011 Operating Offshore / Onshore Technical & Business teams Key statistics gathered and used to monitor technical team progress and issues Tied statistics back to business goals and needs Monitored both operation and developmental statistics Monitored release schedule and interaction with technical / business processes Effort estimates and actuals versus Phase comparison to improve planning process Defects initiation and Phase comparison to address quality issues Action plan and Retrospectives
70. page 31 September 21, 2011 Development and Operational Metrics Portal Releases Major Patch Thematic
77. page 38 September 21, 2011 R 5.0 Defect Prevention & Process Improvements Defect Data Analysis of internally found defects: Highlight the PI activities carried out in the review period
79. page 40 September 21, 2011 “The illusion that we are separate from one another is an optical delusion of our consciousness.” Albert Einstein Quote slide
