1 / 54

SW Project Management Project Communication and QA

SW Project Management Project Communication and QA. INFO 420 Glenn Booker. Need for communication. As we’ve seen, IT projects tend to be volatile, so good lines of communication are needed to keep everyone updated

marsha
Télécharger la présentation

SW Project Management Project Communication and QA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SW Project ManagementProject Communication and QA INFO 420 Glenn Booker Chapters 9 & 10

  2. Need for communication • As we’ve seen, IT projects tend to be volatile, so good lines of communication are needed to keep everyone updated • Else you implement unneeded functionality, work to outdated specs or designs, etc. • How well is the plan being followed? • How do we make good adjustments? Chapters 9 & 10

  3. Need for communication • Lack of communication is a major cause of IT project failure • 28% of a CompTIA survey said poor communication was the #1 reason for failure • 18% cited insufficient resource planning • 13% unrealistic deadlines • Could communication affect the latter two? Chapters 9 & 10

  4. Communication includes • Communication planning • How will information and knowledge be stored? • Who gets what information when? • Who can access what information? • Who updates information? • What forms of communication are used? Chapters 9 & 10

  5. Communication includes • Information distribution • Get the right info to the right people at the right time in the right format • Performance reporting • Includes communication with stakeholders • Managing stakeholders • Keep info needs and issues met Chapters 9 & 10

  6. Communication needs • A project communication plan can include what information goes to each stakeholder and how that information is delivered • Formal methods – reports, reviews, meetings • Informal methods – email, conversations • What does each stakeholder want and need to know about the project? Chapters 9 & 10

  7. Communication needs • Not everyone should see detailed financial data, technical choices and decisions, etc. • Many more might want a broad overview of progress to date, projected project completion (budget, schedule) • No one likes surprises • Can reflect poorly on management if unprepared (FEMA, New Orleans) Chapters 9 & 10

  8. Monitor and control project • Events during a project could result in sudden changes in productivity, focus • Need a process for making changes to project schedule, scope, budget to accommodate the unexpected • Don’t pretend to be on track if you’re not! • Honesty up front is often the best approach Chapters 9 & 10

  9. Monitor and control project • Key management choices often include • Reassign resources • Adjust the plan – scope, schedule, budget, quality • So need an early warning system to identify problems as soon as possible • Hence obsessive comparison ‘plan vs actuals’ Chapters 9 & 10

  10. Monitor and control project • Part of this process is measuring performance, which also helps hold people accountable • Side benefit to see if resources are being utilized effectively • Controls can be within project, or external (e.g. government or industry standards) Chapters 9 & 10

  11. Communications plan • The project communications plan can be informal or formal, depending on the size and nature of the project • Key is to keep stakeholders informed • Even (especially?) those who oppose or don’t support the project! • Keep your friends close, and your enemies closer! Chapters 9 & 10

  12. Communications plan contents • A communications plan can be fairly simple, depending on project complexity • Identify all the stakeholders; for each • What kinds of information do they need? • Consider technical and project information, and what level of detail is appropriate • How often? Daily/weekly/monthly/quarterly? • Discuss the reasons or rationale Chapters 9 & 10

  13. Communications plan contents • Consider whether some kinds of reports can be made general enough to meet the needs of several stakeholders • Or is it better to customize content for each? • Information might include the usual suspects • Scope, budget, schedule, quality, risk Chapters 9 & 10

  14. Communications plan contents • Consider also who should get specific deliverables from the project • Phase reports, design reviews, release descriptions, test reports, etc. – who gets them? Why? • What medium or format will communication take? • Tweets, PDF, email, meetings, telecons, etc. Chapters 9 & 10

  15. Communications plan contents • Timing of information varies in importance • Some stakeholders are key decision makers, others might have only casual or passing interest in project status (vendors, end users) Chapters 9 & 10

  16. Project metrics • What you measure focuses people’s attention • How would you respond differently if the course grade was 90% participation? • Here we want to measure the basics • Scope, schedule, budget, resources, quality, risk Chapters 9 & 10

  17. Project metrics • A good metric should be • Understandable • Quantifiable • Cost effective to collect • Proven effective • High impact - meaningful Chapters 9 & 10

  18. Project metrics • Guidelines for a measurement system • Measurement system should allow project team to measure progress • Team should design their own measurement system • Adopt only a few measures (avoid overload) • Measures should track results and progress Chapters 9 & 10

  19. Earned Value • Earned Value balances cost, schedule, and the amount of work accomplished (the “earned value”) during a project • Each task’s planned cost is called the planned value (PV) of that task • This assumes you’ve planned out all the project tasks from the start! Chapters 9 & 10

  20. Earned Value • The planned completion of the project is the budget at completion (BAC), both time and money • So the BAC is the end of the PV curve • The actual expenditures at any point in time is the actual cost (AC) • The earned value (EV) is the planned value of tasks you’ve actually finished Chapters 9 & 10

  21. Earned Value • This lets us separate how much has been spent from what really got accomplished • Define • Cost variance (CV, $) = EV – AC • Schedule variance (SV, $) = EV – PV • Cost performance index (CPI) = EV/AC • Schedule performance index (SPI) = EV/PV Chapters 9 & 10

  22. Earned Value • For historic note • AC was called ACWP (actual cost of work performed) • PV was called BCWS (budgeted cost of work scheduled) • EV was called BCWP (budgeted cost of work performed) • Many sources will use this terminology Chapters 9 & 10

  23. Earned Value • The best trick is that we can predict when the project will finish, the Estimate At Completion (EAC) • EAC(cost) = BAC(cost) / CPI • EAC(schedule) = BAC(schedule) / SPI • These assume we’re using a long term trend for CPI and SPI Chapters 9 & 10

  24. Earned Value • There are many other EV metrics https://www.goldpractices.com/practices/tev/index.php Chapters 9 & 10

  25. Earned Value • The value assigned to each task can be handled in many ways • Common ways are • Give ½ of EV at start of task, the other ½ when completed (50/50), or give full EV only when task is completed (0/100) • Assign some ‘percent complete’ to task • Watch for subjective assessments! Chapters 9 & 10

  26. Reporting performance • Project reporting tends to fall into categories • Reviews, focusing on specific deliverables, milestones, or project phases • Review work accomplished, address issues, get approval to move on • Status reporting • Compare actuals to plan, reasons for variances Chapters 9 & 10

  27. Reporting performance • Progress reporting • Review accomplishments, compare to plans • Forecast reporting • Predict future status of project (cost, schedule) • Might use trend analysis Chapters 9 & 10

  28. Information distribution • Again, consider how information will be distributed • Face to face meetings • Telephone, email, other electronic devices • Collaboration technology (NetMeeting, Blackboard, wikis, etc.) Chapters 9 & 10

  29. IT Project Quality Management Chapters 9 & 10

  30. Quality? • What is quality? • If something has quality, how can you tell? • Are features and quality connected? • Who defines what quality is for a product? Chapters 9 & 10

  31. Quality • Often in a business context, ‘fitness for use’ or ‘conformance to requirements’ are key elements of a quality product • In short, it does what it’s supposed to do • Is that enough? Chapters 9 & 10

  32. Quality management processes • Project quality management (PQM) processes (per the usual PMBOK) include • Quality planning • What standards need to be met, and how? • Quality assurance – compare project performance against those standards • Quality control – ensure product quality • Support defect prevention & process improvement Chapters 9 & 10

  33. Quality scope • Hence quality management includes both looking out for product quality (the system being created or maintained) as well as process quality (are you following good practices?) Chapters 9 & 10

  34. Quality costs • Good quality often pays for itself in the long run • Avoids defects, rework, bad publicity, etc. • DIA/DEN airport baggage system quality issues cost $1M per day in lost revenue Chapters 9 & 10

  35. Quality tools and approaches • The scientific management approach was developed by Frederic Taylor • Studied the relationship between people and tasks, to improve the efficiency of each task and subtask by reducing variability in how they were performed, just do essential actions • Also did time-motion studies Chapters 9 & 10

  36. Control charts • Walter Shewhart gave us control charts • Provide a more scientific and objective basis for understanding variability • Plots the mean, upper and lower control limits (+/- 3s from the mean) • Normal random variation is due to common causes, want to eliminate assignable causes • The basis for statistical process control Chapters 9 & 10

  37. Total Quality Movement • W Edwards Deming is legendary in quality management circles • Empowered workers to contribute to quality • Worked with Shewhart • First taught Japanese managers, later the US caught on • Famous for 14 points of quality Chapters 9 & 10

  38. Quality planning, improvement • Joseph Juran gave us the ‘fitness for use’ definition of quality • Quality is not an accident, it must be planned • Recognize internal and external customers • The quality trilogy – quality planning, control, and improvement – make a Quality Planning Road Map Chapters 9 & 10

  39. Quality diagrams & graphs • Kaoru Ishikawa, a Deming pupil, gave us ways to present quality data • Gave us the fishbone diagram, one of Ishikawa’s seven basic quality tools • Alfred Pareto gave us his diagram • And process flow charts are also helpful Chapters 9 & 10

  40. Quality standards • ISO 9000 • CMMI (Capability Maturity Model Integration) • Six Sigma • Awards • Malcolm Baldrige National Quality Award • Deming Prize Chapters 9 & 10

  41. Quality systems • ISO 9000 is the best known quality management system • Also includes ISO 9001 and 9004 stds • Facility-based • Originally for manufacturing, now very broad • Certification checks about every six months Chapters 9 & 10

  42. Quality systems • CMMI is based on the CMM developed in the 1980’s by the Software Engineering Institute at Carnegie Mellon University • Original goal was to fix the software development crisis • Led to similar structures for systems engineering, software acquisition, personnel management, and other areas Chapters 9 & 10

  43. CMMI • Led to hard time choosing the ‘right’ CMM for a given project • So now instead, CMMI has “simplified” the problem to three sets of models • CMM/CMMI has five levels of process maturity • Initial, Repeatable, Defined, Managed, Optimizing Chapters 9 & 10

  44. CMMI • Within each level (after level 1) there are Key Process Areas – to meet goals • Level 2 includes CM, QA, project tracking & oversight, project planning, and req’ts mgmt • Level 4 adds statistical process control for key processes • Level 5 adds defect prevention and continuous process improvement Chapters 9 & 10

  45. Quality systems • Six Sigma was created by Motorola • Based on fanatical process control • Aims for under 3.4 defects per million opportunities • Known for green and black belts • Source of DMAIC improvement framework • Define goals, measure, analyze, improve, control Chapters 9 & 10

  46. Quality planning • All of these standards agree that • Focus on customer satisfaction is essential • Quality is by prevention, not inspection • Improve the process to improve the product • Quality is everyone’s job • Fact-based management is critical (which points to measurement) Chapters 9 & 10

  47. Quality planning • So how does all this apply to a project? • Need to choose an approach for PQM • Which standard(s) are best to follow, if any? • Again, we’re driven by the project MOV • That defines the project scope and req’ts • So we need project and quality standards that will ensure we meet those requirements Chapters 9 & 10

  48. Metrics • We looked at ways to present quality data • How choose what to measure? • Map to project goals, e.g. using GQ(I)M • Define product, process, resource, and/or tool metrics that are appropriate for your MOV Chapters 9 & 10

  49. V&V • Verification and Validation (V&V) are key aspects, often associated with testing • Verification makes sure the product meets its requirements • Often done via reviews, walk-throughs, inspections • Validation makes sure the product meets the expectations and needs of the customer • Customer testing, a and b tests Chapters 9 & 10

  50. Change control • Change control becomes necessary when the team has two or more people in it • Prevents two+ people editing the same thing • Allows you to roll back to a previous version of the system if the new one bites • Supports good backup strategies • Defines the final version of the system Chapters 9 & 10

More Related