Name of Your Country


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

Name of Your Country

  1. 1. National Association of Legislative Information Technology 2007 Professional Development Seminar Project Management PN Narayanan PMP Delaware Department of Technology and Information
  2. 2. Title and Scope • Project Management Methodologies: What and Why – an examination of various methodologies with an eye to what has worked/not worked with legislative IT projects and why; how methods fit with project team and stakeholders; discussions of actual experiences.
  3. 3. Objectives • Have Fun • Learn the history of project management and the importance of project management. • Learn basic project management terms • Distinguish projects from programs. • Describe the Project Life Cycle, Five phases, and nine knowledge areas. • Explain different organization structures and Team models and their impacts on PM tasks. • Learn different software development Life Cycles • Discuss real life projects from users’ experiences and learn from challenges.
  4. 4. Housekeeping • Please put Cell phones and Blackberries in buzzer mode. • An active participation to make it fun. • Feel free to stop the presentation for questions, clarifications and opinions. • Share your experience
  5. 5. Project Management ? 1994: The Standish Group study shows the Schedule overrun was 222%, cost overrun was 189%. 16.2 % Successful, 52.7% challenged, and 31.1% Failure 2000: The Standish group study shows marked improvement in Project resolution. The schedule overrun came down to 63% and cost overrun came down to 45%. 2006: Chaos Report shows 35% successful 46% challenged And 19% failed (source: PM Network June 2007)
  6. 6. Looking Back It is simple to make things difficult, and it is difficult to make things Simple Project delays, Ad hoc project management Teams work in silos Front page on Newspapers No Change Management
  7. 7. State of Delaware • Major Project office • Chief Program Officer • Dedicated Change management • E-Gov Program Portal no 1 in Nation, BOW • 800 MHZ, ERP programs • PMI Dover Chapter • Certified PM and CMs • Governor’s proclamation • Quality Month, Project management day
  8. 8. Basics of PM….. • Project does not just happen , it is shaped by decision, decision, and decisions…… Characteristics of projects • Unique • A start and finish • Multiple phases • Whereas • Processes are repeatable, Continuous, do definite end
  9. 9. Program- Project-- Process • Multiple flights – Program • Each flight ----Project • Media Reporting--- Process
  10. 10. Basics of PM…..Cont Business Technology Requirement Vision change Strategy Change Readiness Assessment Team Design Job/Role Skill Description Assessment Team Building Update Standards Lessons & procedures Execution Learned Acceptance by user Transfer to Maintenance
  11. 11. PM Phases Planning Process Initiating Process Controlling/Executing Process Arrows represent "deliverables" Controlling Executing Process Process Closing Process Courtesy: PMI
  12. 12. PM Phases and Stress Stress Level 1% 18% 17% Initiation Planning Execution Controlling 31% 33% Closing Source: PM Network July 2007
  13. 13. Typical Cycle Cost and Staffing level Courtesy: PMI Time
  14. 14. Stakeholders influence over project life Influence of Stakeholders High Cost of Changes Low Courtesy: PMI Project Time ---
  15. 15. Relationship of Stakeholders Project Sponsor PM Stakeholders influence over project life PM Team Project Team Project Stakeholders Courtesy: PMI
  16. 16. When implementing a project, an organization needs to consider not only technology but also process and people. Project Implementations Process Technology People Current Future Current Future Current Future process Process Technology Technology Organizations Organizations What work steps occur What technology is used How are people utilized
  17. 17. Nine Knowledge Areas • Scope • Cost • Time • Quality • Risk • Communication • Procurement • Integration • Human Resources Courtesy: PMI
  18. 18. Scope Management • Scope Planning • Scope Definition • Create WBS • Scope verification • Scope Control
  19. 19. Requirement Gathering – A Collaborative effort Gathered Real Strategies • Design feedback sessions • Customer Sign off Product Features Real Low/Medium level Gathered Customer participation High level Product Features Customer participation
  20. 20. Scope – Requirement Gathering The sooner you begin coding the later you finish. Great, I know I can count on you Need a report by COB today, Why not ….
  21. 21. Scope - From the perspective of stakeholders Project champion A user will tell you anything We need a LIS you ask, but nothing more Project Sponsor High level Requirements Project Manager Detailed Design
  22. 22. Sample Work break down structure Super bowl Two approaches Top down How to negotiate with your spouse Progressively detail the work. Bottom up Future trip Identify all work to be done Bribe with a gift to Hawaii and then group Procure Have Tickets Have Brochures ready Ready
  23. 23. Cost Management • Cost Estimating • Cost control • Cost budgeting
  24. 24. Schedule Cost relationship Estimates too low Minimum time Costs high Inadequate planning Actual mistakes Schedule Estimates too high Costs high Actual = Estimate Estimated Schedule
  25. 25. Time Management • Activity Definition • Activity sequencing • Activity Resource estimating • Activity Duration estimating • Schedule Development • Schedule control
  26. 26. Schedule • Exercise
  27. 27. Schedule pressures More Schedule pressure More More Schedule Stress Project owner/ slips Authority More Mistakes Project Manager If the critical path says 6 months I am confident “you can work hard to get it done in 4 months”
  28. 28. Schedule Risks Shortest Ideal possible Optimistic Schedule time Warning: dates Probability of completing in a calendar on time are closer than they appear to be. Time Ideal Time
  29. 29. Quality Management • Quality Planning • Quality Assurance • Quality Control • The Fix it Quality Approach • The inspect it in Approach • The Built it in Approach • The Design it in Approach
  30. 30. Risk Management • What you don't know hurts you • Risk management planning • Risk identifications • Qualitative Risk analysis • Quantitative Risk analysis • Risk response planning • Risk monitoring and control
  31. 31. Effective Risk management • Bottom up project related issues • Top down Organizational issues • Not all risks are equal • Risk becomes issues….. • Large projects needs more frequent monitoring
  32. 32. Schedule • Exercise
  33. 33. Communication management • Communication planning • Information distribution • Performance reporting • Manage stakeholders
  34. 34. Communication Paths 2 people One path Of several possible 3 people 3 paths interpretations of a communication, the 4 people 6 paths least convenient is 10 people 45 paths the correct one. 50 people 1200 paths No of channels= n(n-1)/2
  35. 35. Procurement management • Plan purchases and acquisitions • Plan contracting • Request seller responses • Select sellers • Contract administration • Contract closure
  36. 36. Integration management • Develop Project charter • Develop preliminary scope statement • Develop Project plan • Direct and Manage Project execution • Monitor and Control Project work • Integrated change control • Close project
  37. 37. Human Resources • HR planning • Acquire Project team (Beg, Borrow, bribe, demand) • Develop Project team • Manage Project team (Assign task, get status, manage conflict)
  38. 38. Team Selection • Best of your staff… • Interested • Available , can dedicate time • Right skill set • Positive attitude • Energetic… some projects will become a drag (you need a marathon runner than a sprinter) • If it is a big project have dedicated scribe for taking minutes and organizing (Scheduling is a nightmare everywhere – everyone is so busy)
  39. 39. Role of PM • PMs are accountable for the project success • Responsible for Processes and deliverables • Will find resources, remove conflicts (if requires escalation), make choices and decisions on project tasks. • Will manage the budget , schedule, Scope, Risk, and Quality
  40. 40. What does PM do? Staffing Controlling Planning Decision Leading PM PM making Motivating Organizing Communicating
  41. 41. Lunch Break
  42. 42. Welcome Back • Exercise
  43. 43. Lessons Learned • Every Project is a great Teacher, you always learn from every project irrespective of whether it is a success or failure • Capture Lessons learned through the project, not at the end. • Categorize • What Worked very well – Do it again • Was difficult but worked out at the end • Did not work very well – Don’t try again • Wish we would have done this. It is costly wisdom that is bought by experience. Author: Roger Ascham Source: Schoolmaster
  44. 44. Project tailoring • Not all projects are same • One size fit all is a myth when it concerns project • Based on the complexity of the project they may be classified into low, medium or high and accordingly the PM processes can tailored. • Low – A Charter, Scope, Schedule, budget, test scripts, closure, lessons learned. • Medium: All the above, risk plan, cost and procurement plan • High- All the above, Scope, change orders, communication and change management plans.
  45. 45. Managing small projects • Small projects have a high probability for success • Still needs attention and standard processes • May want to group small projects into a program or portfolio (not to be confused with Portfolio management) • Schedule is mandatory for all projects • Sign off on requirements for small projects is vital • Issue log instead of Risk management plan • Frequent Status updates (since small project tend to close soon, if not closely monitored may end up with undesirable product)
  46. 46. Managing a process like a project • Even at times processes can me managed as a project • For example, Office upgrade, Operating system upgrade • A clearly defined schedule is the best bet to complete the repeatable processes at least a WBS (Work break down structure) E.g. Air line pilots check list • A feed back system to refine the processes through lessons learned process will help to create a lot of efficiency. • Even process management requires clear communication and change management. E.g. Patch updates, Firewall changes, Main frame upgrades or VMWare updates.
  47. 47. Communicating with Techies • Generalization apart Techie’s tends to be Introverts. • Developers thinks in a logical form • Coding is their favorites and not the process • You know by now they dislike documentation • Testing is not their forte… • Challenge them only when you know their subject very well (will gain respect) • Fix the broken windows
  48. 48. Legislative Project Challenges • Complicated Process – highly flexible/dynamic rules and interpretations. • Sponsorship Clarity • Ownership of the application • Political process constraints • Staff Resources • Schedule constraints • Technology awareness and barriers • Funding
  49. 49. Scope: How to collect User Requirements • Video – Yes Prime Minster CD 1 Title 3 chapter 5 • Opening Files--- Relative Sequence • Open ended questions initially – specific questions later • Record the conversations for future clarifications • Develop a process work flow diagram
  50. 50. Life Cycle Models • Pure Water Fall • Modified Water fall • Sashmi (water fall with phases) • Water fall with sub projects • Water fall with Risk reduction • Code and Fix • Spiral • Evolutionary Prototyping
  51. 51. Life Cycle Models --- Continued • Staged Delivery • Design to schedule • Evolutionary Delivery • Design to Tools
  52. 52. Pure Water Fall + Most popular model Concept + Quality + Good for inexperienced teams (structure) Req Analysis Architectural design Detailed Design Coding & - Cost and schedule Debugging - Lack of flexibility - backing up is difficult System - few visible progress till end testing
  53. 53. Modified Water fall • Sashmi (water fall with phases) • Water fall with sub projects • Water fall with Risk reduction Concept Concept Concept Req Analysis Req Analysis System testing Architectural design Architectural design Risk reduction for High risk nucleus
  54. 54. Code and Fix Spec ? Code and Fix Product ? Though not very useful, most common. If you have not selected / known any other model you must be using this one. + No Over head - no measure of progress + Needs little experience - poor quality - if you are not luck very costly
  55. 55. Spiral This is the most sophisticated and risk oriented model. In simple terms it breaks a complex large project into smaller sub projects. Each mini projects addresses one or more major risks and once all risks are addressed and resolved, the spiral ends up as a water fall. +++ Early risk identifications, early risk mitigations, Higher rate of success in large complex projects. ---- Complex, Detailed oriented at early stages, requires knowledgeable managements Fondly this model is also called as Cinnamon role model. Risk Analysis Identify and mitigate risks Determine Objectives, alternates, limitations Evaluate Alternates Plan the next Develop code iterations through iterations
  56. 56. Evolutionary Prototyping • Develop system concepts as you move through the project. Design and Implement Complete and Initial initial Refine prototype release concept prototype Until agreement prototype ++ when requirement changes rapidly --at start impossible to know how long it will Useful when the application area not clear take. Provides steady visible sign of progress
  57. 57. Staged Delivery • Deliver the product in usable increments through out the life cycle. • With proper planning this model can deliver the most critical functionality first Concept Req Analysis Architectural design Design, code, debug, test and deliver -- Needs very careful planning ++ Useful functionality at the hand of Customer. Tangible sign progress
  58. 58. Design to schedule • Similar to Staged delivery but limited by schedule or resources • Schedule driven, high priority first and medium and low later ++ Useful functionality at the hand of -- May not get through all stages customer sooner. Tangible sign progress Concept Req Analysis Architectural design High priority Design, code, debug, test and deliver Medium Priority Design, code, debug, test and deliver Run out of money/time Medium/low priority Design, code, debug, test and deliver
  59. 59. Evolutionary Delivery • Mid ground between evolutionary prototyping and Staged Delivery Concept Final version Req Analysis Architectural design V1 Include Deliver feedback V1 Get feedback
  60. 60. Design to Tools • Powerful flexible tools allows us to perform rapid development Functionality supported by the tool Functionally scarified Ideal Functionality Functionality that will be built
  61. 61. Factors for choosing the most rapid life cycle • Understanding of requirements • How well the Architecture is defined and understood • Reliability • Risk tolerance • Any schedule constraints • Does customer prefers visible progress? • Will the project require mid course corrections?
  62. 62. Team Models • Business Team • Chief Programmer Team • Skunkworks Team • Feature Team • Search and Rescue Team • SWAT team • Professional Athletic Team • Theater Team • Large Teams
  63. 63. Business team • Peer Group headed by a technical lead • Aside from Technical lead the team members all have equal status • The lead is chosen on the basis of technical expertise rather than management proficiency. • It is adaptable to all kinds of projects which its strength as well the weakness.
  64. 64. Chief Programmer Team • Developed by IBM in late 60s • Based on the concept of Surgical team and takes advantage of the fact that specialists tend to out perform generalist • Chief programmer is ultimately responsible for virtually all the decisions of the project. • Good for creative projects, tactical execution projects • Finding a superstar and retaining are challenges
  65. 65. Feature Team • Based on features like development, QA, documentation etc • Traditional hierarchical reporting structures • Advantage of empowerment and accountability • Good for problem resolution project and creative projects • The overhead of Feature team will be wasted on Tactical executions. • If all the tasks are well defined this team will have little to contribute
  66. 66. Skunkworks Team • A free form team where a leader emerges (can also designate) • Team has freedom to organize as it wishes • Freed from normal bureaucratic structure • It creates intense ownership, buy in is easy • Not much of a visibility • Good for exploratory project bad for rapid development projects
  67. 67. Search and Rescue Team • A team with very specific knowledge of piece of software and its business processes. • For example if pay roll is to run by midnight you need a team to resolve any problem immediately not next day. • Best suited for problem solving rather than development • Not good for creativity or tactical execution due to limited spread of knowledge.
  68. 68. SWAT team (Skilled With Advanced Tools) • Part of James Martin’s RAD methodology • A specific knowledge of an RDBMS or Software framework • They could be permanent team not always perform their SWAT duties • Good for Tactical execution, or problem solving • Team member will have high trust
  69. 69. Professional Athletic Team • Typical in Shrink wrap software production • Highly skilled star programmers, architects best in their field • Athletic teams have highly specialized roles ( WR (wide receiver) don’t want to be a QB) • Manager like NFL could a be former star performer • Best for tactical execution, software development
  70. 70. Theater Team • This team is characterized by strong direction and lot of negotiations about project role • Software manager plays the role of the producer stay away from an active role • PM serves as Director, the individual players can use creativity as long it does not conflict with the director’s vision • Good for team of strong personalities • Good for project where lot of technologies converge
  71. 71. Large Teams • Large teams are generally organized like a large corporation . • Communication will be a challenge • Nightmare for the project manager • Projects like ERP, Vista development
  72. 72. Why Projects Fail ? • Incomplete Requirements 13.1% • Lack of user Involvement 12.4% • Lack of Resources 10.6% • Unrealistic expectations 9.9% • Lack of executive support 9.3% • Changing Requirements & Spec 8.7% • Lack of planning 8.1% • Did not need is any longer 7.5% • Lack of IT management 6.2% • Technology Illiteracy 4.3% • Others 9.9% Source: 1994 Chaos Report
  73. 73. Project Success Factors • User Involvement 15.9% • Executive management support 13.9% • Clear Statement of Requirements 13.0% • Proper Planning 9.6% • Realistic Expectations 8.2% • Smaller project Milestones 7.7% • Competent staff 7.2% • Ownership 5.3% • Clear vision and Objectives 2.9% • Hard working focused staff 2.4% • Others 13.9% Source: 1994 Chaos Report
  74. 74. Comparison Project Failures Project Success • Incomplete Requirements 13.1% • User Involvement 15.9% • Lack of user Involvement 12.4% • Executive management support 13.9% • Lack of Resources 10.6% • Clear Statement of Requirements 13.0% • Unrealistic expectations 9.9% • Proper Planning 9.6% • Lack of executive support 9.3% • Realistic Expectations 8.2% • Changing Requirements & Spec • Smaller project Milestones 7.7% 8.7% • Competent staff 7.2% • Lack of planning 8.1% • Ownership 5.3% • Did not need it any longer 7.5% • Clear vision and Objectives 2.9% • Lack of IT management 6.2% • Hard working focused staff 2.4% • Technology Illiteracy 4.3% • Others 13.9% • Others 9.9% Source: 1994 Chaos Report
  75. 75. Fast Forward 2006 • Project Challenges in 2006 • Lack of clarity in scope 64% • Project Changes not managed well 43% • Shifting Org priorities 36% • Lack of PM skills 36% • Loss of control due inadequate Project plan 36% Source: PM Network Magazine
  77. 77. Closing remarks ---- Any how Project Management is the art of creating the illusion that any outcome is the result of predetermined , deliberate acts when , in fact, it was dumb luck Kerzner
  78. 78. Reference/Bibliography • PMI – Project Management Institute • Rapid Development – Steve McConnell • Management – Kreitner • PM Network Magazine • Yes Prime Minster Video - BBC