MGMT631 Slides Seven.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
  • The project plan identifies the cost, time and resources needed to deliver the scope and quality. At the end of planning the project is in equilibrium, but immediately changes and scope creep begin to impact this equilibrium. It is then the project manager’s task to control these dynamics.
  • MGMT631 Slides Seven.ppt

    1. 1. MGMT631 Project Management Slides Seven Fall 2009 David Harris
    2. 2. Session Objectives <ul><li>Balancing the project (Verzuh Chapt 9) </li></ul><ul><li>Quality issues & management </li></ul><ul><ul><li>quality initiatives & management systems include ISO certification, Six Sigma & Capability Maturity Model (CMM) </li></ul></ul><ul><ul><li>(PMBOK) project quality management (PQM) supports quality planning, quality assurance, quality control & continuous improvement of the project’s products & supporting processes </li></ul></ul><ul><ul><li>Distinguish validation & verification activities & how they support IT project quality management </li></ul></ul>Fall 2009
    3. 3. Balancing Projects (Verzuh #9) <ul><li>Projects are dynamic </li></ul><ul><li>So we need </li></ul><ul><ul><li>to manage scope throughout </li></ul></ul><ul><ul><li>to keep time in balance </li></ul></ul><ul><ul><li>to keep dollars in balance </li></ul></ul><ul><ul><li>to keep resources in balance </li></ul></ul>Fall 2009
    4. 4. Project Dynamics: The Triple Constraints Fall 2009 Scope Quality Cost Time Resources
    5. 5. Balancing Projects (cont.) <ul><li>Balancing a project (three levels) </li></ul><ul><ul><li>project itself, balance to keep on track </li></ul></ul><ul><ul><ul><li>cost, schedule, quality </li></ul></ul></ul><ul><ul><li>if not re-evaluate business case </li></ul></ul><ul><ul><li>may need to rebalance at enterprise level </li></ul></ul>Fall 2009
    6. 6. Balancing at Project Level <ul><li>Re-estimate to check </li></ul><ul><li>Reassign, take advantage of float </li></ul><ul><li>Add people but . . . </li></ul>Fall 2009 Cutting functionality & performance not options BUT what about phases?
    7. 7. Balancing at Project Level (cont.) <ul><li>Bring in expertise </li></ul><ul><ul><li>from inside organization </li></ul></ul><ul><ul><li>outsource (be aware of vendor risks) </li></ul></ul><ul><li>Outsource entire project </li></ul><ul><ul><li>your org is still responsible </li></ul></ul><ul><ul><li>risks </li></ul></ul><ul><li>Work overtime, but . . . </li></ul>Fall 2009
    8. 8. Balancing at Business Case Level <ul><li>Reduce scope </li></ul><ul><li>Fast tracking </li></ul><ul><ul><li>overlap rather than in sequence </li></ul></ul><ul><ul><li>can reduce by up to 40% </li></ul></ul><ul><ul><li>but risky </li></ul></ul><ul><li>Phase product delivery </li></ul><ul><ul><li>deliver something ASAP </li></ul></ul><ul><li>Quick & Dirty, then rebuild it right Translate “Quick & Dirty” as “Interim Solution” </li></ul><ul><li>If all else fails becomes enterprise issue </li></ul>Fall 2009
    9. 9. Quality of IT Projects <ul><li>Jokes about the poor quality of IT products </li></ul><ul><li>People seem to accept systems being down occasionally or needing to reboot their PCs </li></ul><ul><li>Many examples in the news about quality problems related to IT </li></ul>Fall 2009
    10. 10. What Is Quality? <ul><li>ISO: International Organization for Standardization defines quality as: </li></ul><ul><li>The totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs </li></ul><ul><li>Other define quality based on </li></ul><ul><ul><li>conformance to requirements: meeting written specifications (? perceptions) </li></ul></ul><ul><ul><li>fitness for use: ensuring a product can be used as it was intended </li></ul></ul>Fall 2009
    11. 11. Modern Quality Management <ul><li>Modern quality management </li></ul><ul><ul><li>requires customer satisfaction </li></ul></ul><ul><ul><li>prefers prevention to inspection </li></ul></ul><ul><ul><li>recognizes management responsibility for quality </li></ul></ul><ul><li>Noteworthy quality (TQM) experts include Deming, Juran, Crosby, Ishikawa, Taguchi, Feigenbaum </li></ul>Fall 2009
    12. 12. Business Reengineering & Quality Management Business Quality Improvement Business Reengineering Definition Target Potential Payback Risk What Changes? Primary Enablers Incrementally Improving Existing Processes Radically Redesigning Business Systems Any Process Strategic Business Processes 10%-50% Improvements 10-Fold Improvements Low High Same Jobs - More Efficient Big Job Cuts; New Jobs; Major Job Redesign IT and Work Simplification IT and Organizational Redesign
    13. 13. Wysocki Continous Quality Management Model Improving business processes
    14. 14. Project Quality Management (PQM) - PMBOK <ul><li>The processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, and responsibility and implements them by means of quality planning, quality assurance, quality control, and quality improvement within the quality system. </li></ul>
    15. 15. PMBOK – Project Quality Management Process <ul><li>Quality Planning </li></ul><ul><ul><li>Determining which quality standards are important and how they will be met. </li></ul></ul><ul><li>Quality Assurance </li></ul><ul><ul><li>Evaluating overall project performance to ensure quality standards are being met. </li></ul></ul><ul><li>Quality Control </li></ul><ul><ul><li>Monitoring the activities and results of the project to ensure that the project complies with the quality standards. </li></ul></ul>Fall 2009
    16. 16. PQM <ul><li>Focuses on project’s products </li></ul><ul><ul><li>project’s most important product is the information system solution that the project team must deliver </li></ul></ul><ul><li>Focuses on project process </li></ul><ul><ul><li>the activities, methods, materials, and measurements used to produce the product or service </li></ul></ul><ul><ul><li>part of a quality chain where outputs of one process serve as inputs to other project management processes </li></ul></ul>Fall 2009
    17. 17. Programs & People <ul><li>ISO Certification </li></ul><ul><li>Six Sigma initiatives </li></ul><ul><li>Awards </li></ul><ul><ul><li>Deming Prize </li></ul></ul><ul><ul><li>Malcolm Baldridge National Quality Award </li></ul></ul><ul><li>Capability Maturity Model (CMM) </li></ul><ul><li>Shewhart </li></ul><ul><li>Deming </li></ul><ul><li>Juran </li></ul><ul><li>Ishikawa </li></ul><ul><li>Crosby </li></ul>Fall 2009
    18. 18. Control Chart for a Process within Statistical Control Control Chart for a Process Not in Statistical Control
    19. 19. Quality Systems <ul><li>International Organization for Standardization (ISO) </li></ul><ul><ul><li>Derived from Greek word “isos,” meaning equal </li></ul></ul><ul><ul><li>Formed in 1947 </li></ul></ul><ul><ul><li>Today has over 130 members “to facilitate the international coordination and unification of industrial standards.” </li></ul></ul><ul><ul><li>Standards make up ISO 9000 (organizations) & ISO 14000 (environmental) families </li></ul></ul>Fall 2009
    20. 20. Quality Systems I SO 9000 Principles <ul><li>Customer Focus </li></ul><ul><li>Leadership </li></ul><ul><li>Involvement of People </li></ul><ul><li>Process Approach </li></ul><ul><li>System Approach to Management </li></ul><ul><li>Continual Improvement </li></ul><ul><li>Factual Approach to Decision Making </li></ul><ul><li>importance of metrics </li></ul><ul><li>Mutually Beneficial Supplier Relationships </li></ul>Fall 2009
    21. 21. Quality Systems 6 Sigma <ul><li>Originated by Motorola </li></ul><ul><li>Based on competitive pressures in 1980s – “Our quality stinks” </li></ul>Fall 2009 Sigma Defects Per Million 1  690,000 2  308,537 3  66,807 4  6,210 5  233 6  3.4
    22. 22. Quality Systems 6 Sigma <ul><li>Six Sigma framework </li></ul><ul><li>(D-M-A-I-C cycle) </li></ul><ul><ul><li>Define </li></ul></ul><ul><ul><li>Measure </li></ul></ul><ul><ul><li>Analyze </li></ul></ul><ul><ul><li>Improve </li></ul></ul><ul><ul><li>Control </li></ul></ul>Fall 2009
    23. 23. Quality Systems: Capability Maturity Model (CMM) <ul><li>Software Engineering Institute (SEI) at Carnegie-Mellon University </li></ul><ul><li>set of recommended practices for a set of key process areas specific to software development. </li></ul><ul><li>guidance as to how organization can best control its processes for developing & maintaining software. </li></ul><ul><li>path for helping organizations evolve their current software processes toward software engineering & management excellence </li></ul>Fall 2009
    24. 24. Levels of Software Process Maturity Fall 2009
    25. 25. <ul><li>Focus on customer satisfaction </li></ul><ul><li>Prevention not inspection </li></ul><ul><li>Improve the process to improve the product </li></ul><ul><li>Quality is everyone’s responsibility </li></ul><ul><li>Fact-based management </li></ul>The IT Project Quality Plan Quality Philosophies & Principles Fall 2009
    26. 26. The IT Project Quality Plan Verification and Validation <ul><li>Verification </li></ul><ul><ul><li>Focuses on process-related activities to ensure that the products & deliverables meet specified requirements before final testing </li></ul></ul><ul><ul><ul><li>Technical Reviews </li></ul></ul></ul><ul><ul><ul><ul><li>Walk throughs </li></ul></ul></ul></ul><ul><ul><ul><li>Business Reviews </li></ul></ul></ul><ul><ul><ul><li>Management Reviews </li></ul></ul></ul><ul><ul><li>Are we building the product the right way? </li></ul></ul>Fall 2009
    27. 27. The IT Project Quality Plan Verification and Validation <ul><li>Validation </li></ul><ul><ul><li>Product-oriented activities that attempt to determine if the system or project deliverables meet the customer or client’s expectations </li></ul></ul><ul><ul><li>Testing - Does the system function as intended and have all the capabilities & features defined in the project’s scope and requirements definition? </li></ul></ul><ul><ul><ul><li>Unit Testing </li></ul></ul></ul><ul><ul><ul><li>Integration Testing </li></ul></ul></ul><ul><ul><ul><li>Systems Testing </li></ul></ul></ul><ul><ul><ul><li>Acceptance Testing </li></ul></ul></ul>Fall 2009
    28. 28. IT Project Quality Plan Monitor and Control <ul><li>Learn, Mature, and Improve </li></ul><ul><ul><li>Lessons learned </li></ul></ul><ul><ul><ul><li>Improvement </li></ul></ul></ul><ul><ul><ul><li>Best Practices </li></ul></ul></ul>Fall 2009
    29. 29. Quality Trade Offs <ul><li>Must quality software be bug-free, on-time, within budget and contain every feature users, stakeholders want? </li></ul><ul><li>Edward Yourdon “When good enough is best” (Byte 9/96) argues </li></ul><ul><ul><li>believing all bugs are evil & all requirements must be met within tight budgets & schedules will lead to failure </li></ul></ul><ul><ul><li>OK for some bugs to into production, but NOT the showstoppers </li></ul></ul>
    30. 30. Quality Trade Offs (cont.) <ul><li>TRIAGE to categorize requirements </li></ul><ul><ul><li>essential (must have) </li></ul></ul><ul><ul><li>important (should have) </li></ul></ul><ul><ul><li>optional (could have) </li></ul></ul><ul><ul><li>complete first two groups, with luck some of third </li></ul></ul><ul><li>Must continue to triage throughout project as needs/requirements change </li></ul>Fall 2009
    31. 31. Quality: Be Practical <ul><li>James Bach </li></ul><ul><ul><li>“ Let’s be practical & make quality about consequences” </li></ul></ul><ul><ul><li>PC Week 8/95 </li></ul></ul><ul><li>Contends there are many trade offs in every project </li></ul><ul><li>We all produce “buggy” software; trick is not to ship wrong bugs </li></ul><ul><li>Quality is optical illusion </li></ul><ul><ul><li>emerges partly from the observed </li></ul></ul><ul><ul><li>partly from observer </li></ul></ul><ul><ul><li>partly from act of observation </li></ul></ul>
    32. 32. Bach (cont.) <ul><li>Argues as utilitarian </li></ul><ul><ul><li>rightness/wrongness not determined by intrinsic goodness, rather by consequences </li></ul></ul><ul><ul><li>Software good enough when benefits outweigh risks for stakeholders </li></ul></ul><ul><li>Involve key stakeholders </li></ul><ul><ul><li>identify consequences of choices </li></ul></ul><ul><ul><li>weigh consequences against benefits </li></ul></ul><ul><li>If we didn’t accept trade offs & flexible definition of quality, there would be no software industry </li></ul><ul><li>Weighing danger/risks of different factors is key to controlling quality </li></ul>
    33. 33. Fall 2009 So Be Flexible
    34. 34. Quality: Organization Influences & Workplace Factors <ul><li>Study by DeMarco & Lister: organizational issues had a much greater influence on programmer productivity than technical environment or programming languages </li></ul><ul><li>Programmer productivity varied by a factor of one to ten across organizations, but only by 21% within same organization </li></ul><ul><li>Study found no correlation between productivity & programming language, years of experience, or salary </li></ul><ul><li>Dedicated workspace & quiet work environment were key factors to improving programmer productivity </li></ul>
    35. 35. Remember Importance of Process Project Management Maturity Model <ul><li>1. Ad-Hoc: no defined systems & processes </li></ul><ul><li>2. Abbreviated: some project management processes & systems </li></ul><ul><li>3. Organized: standardized, documented project management processes & systems that integrated into rest of the organization </li></ul><ul><li>4. Managed: Management collects & uses detailed measures of effectiveness of project management </li></ul><ul><li>5. Adaptive: Feedback from project management process and from piloting innovative ideas & technologies enables continuous improvement </li></ul>
    36. 36. Maturity Levels & Defects <ul><li>Maturity level </li></ul><ul><ul><li>1 </li></ul></ul><ul><ul><li>2 </li></ul></ul><ul><ul><li>3 </li></ul></ul><ul><ul><li>4 </li></ul></ul><ul><ul><li>5 </li></ul></ul><ul><li>Defects E/KSLOC </li></ul><ul><ul><li>12 </li></ul></ul><ul><ul><li>6 </li></ul></ul><ul><ul><li>2.5 </li></ul></ul><ul><ul><li>0.9 </li></ul></ul><ul><ul><li>0.3 </li></ul></ul>Fall 2009
    37. 37. Build Quality into your processes Quality is a matter of perception Be pragmatic
    38. 38. Fall 2009 The End