Project Quality Management PDF

Project Quality Management Quality --\> Defined as "fitness for use -- meeting customer needs". And "conformance to requirements -- meeting a predefined set of standards" Quality focuses on fulfilling requirements and is integrated through out the systems development life cycles. Quality is not def...

Project Quality Management Quality --\> Defined as "fitness for use -- meeting customer needs". And "conformance to requirements -- meeting a predefined set of standards" Quality focuses on fulfilling requirements and is integrated through out the systems development life cycles. Quality is not defined based on features or functionality. It should be defined in terms of dependability and safety as well as these things might be just as important to the customer needs and expectations. The project team and manager must work closely with the customer, user, or sponsor to determine the acceptable standards for quality and grade. As a side note; some products or systems can be built based on a great deal of functionality (i.e. high grade), but are considered "low quality" if they perform poorly and vise versa. Grade -\> centers on the intent of the design. PQM: Project Quality Management *"...the processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken."* - PQM begins with defining the quality standards in terms of grade and tolerances for quality. Will the customer or user be willing to sacrifice quality in order to start using the product, service, or system more quickly? - The project quality planning is determining which quality requirements and/or standards are important for the project and the product and then documenting how compliance will be demonstrated. - **Quality Management Planning:** requires that adequate time and budget are allocated in the project plan for testing and other activities to ensure the project team is building the right product or system and building it the right way. In addition, all of the quality standards along with the processes, metrics, and tools to determine whether these standards are met are documented in a project quality plan. - **Quality Assurance:** focuses on auditing or defining a set of checks and balances to ensure that the project team is following the processes outlined in the quality management plan and that metrics are being collected and analyzed as part of quality control. The project stakeholders should reflect and document lessons learned. This can lead to continuous improvement by identifying best practices and improvements to the quality management planning processes. PQM include both the products (deliverables) and processes of a project - by focusing on both the product and chain of project processes, the project organization can use its resources more efficiently and effectively, minimize errors, and meet or exceed project stakeholder expectations. Examples of the deliverables and processes are below: Project's Deliverables: - Business Case - Project Plan - The IT Solution Project's Processes: - Scope management - Risk management - Requirements Analysis - Design - Implementation Scientific Management (sometimes known as Taylorism) -  founded by Frederic W. Taylor (1856-1915), is a theory of management that analyzes and synthesizes the workflows and has the following rules of thumb: 1. Workers produced so much each day -- no more, no less 2. Believed the production process could be more efficient 3. Many ignored the human factors & believed profits could be increased by speeding up the workers 4. Some think dehumanizing of the workers led to the foundation of labor unions Taylor believed that the production process could become more efficient by increasing the specialization and division of labor using an approach called Scientific Management meaning that a task could be broken down into smaller tasks and studied to identify the best and most efficient way of doing each subtask. Total Quality Management (TQM) Gurus There are 3 TQM Gurus 1. *W. Edwards Deming *- developed 14 Points on Quality Management, a core concept on implementing total quality management; the set of management practices to help companies increase their quality and productivity. As a trained statistician, Deming was interested in the application of statistical theory so that management could make decisions based on facts rather than on intuition. Deming also realized that costly inspections could be eliminated if workers were properly trained and empowered to monitor and control the quality of the items they produced. 2. *Joseph Juran* -- introduced a Quality Trilogy: Quality Planning, Quality Improvement, and Quality Control 3. Deming and Juran have an important impact on Japan after World War II. As Japan was attempting to rebuild after WWII, they faced a problem of having a reputation for inferior products. Having few natural resources, they were dependent on exporting manufactured goods. If their export programs were to be successful they needed to change both the fact and perception of producing low quality products.  4. *Phillip Crosby* -- top-down approach, management's responsibility to set the quality example for others to follow. Quality defined as conformance to requirements based on the customer's needs. Capability Maturity Model Integrated (CMMI) Used to develop and refine an organizations software development process. The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes. **[CMMI Concepts]** ***Process*** A set of activities, methods, or practices and transformations used by people to develop and maintain a product or system and the deliverables associated with project. Included are such things as project plans, design documents, code, test cases, user manuals, and so forth. ***Process capability*** The expected results that can be achieved by following a particular software process. More specifically, the capability of an organization's processes provides a way of predicting the outcomes that can be expected if the same processes are used from one project to the next. ***Process performance*** The actual results that are achieved by following a particular process. Therefore, the actual results achieved through process performance can be compared to the expected results achieved through process capability. ***Process maturity*** The extent to which a particular process is explicitly and consistently defined, managed, measured, controlled, and effectively used throughout the organization. The immature software organization has the software processes are improvised or developed ad hoc.  The **immature software** organization is characterized as being reactive; the project manager and project team spend a great deal of their time reacting to crises or find themselves in a perpetual state of fire fighting. Schedules and budgets are usually exceeded. As a result, the quality and functionality of the software system and the associated project deliverables are often compromised. Project success is determined largely by who is (or who is not) part of the project team. In addition, immature software organizations generally do not have a way of judging or predicting quality. Since these organizations operate in a perpetual crisis mode, there never seems to be enough time to address problem issues or improve the current processes. The **mature software organization** on the other side, has the software processes and the roles of individuals are defined explicitly and communicated throughout the organization. The software processes are consistent throughout the organization and continually improved based on experimentation or experiences. The quality of each software process is monitored so that the products and processes are predictable across different projects. Budgets and schedules are based on past projects so they are more realistic and the project goals and objectives are more likely to be achieved. Mature software organizations are proactive and they are able to follow a set of disciplined processes throughout the software project. The **project's standards** can be defined in terms of the project's deliverables and, most importantly, by the IT solution to be delivered. Once the features, functionality, or requirements are defined, the next step is to identify specific quality attributes or dimensions associated with each project deliverable. A customer-driven quality assurance plan first identifies each customer's requirements, represents them as quality attributes or dimensions, and then translates those dimensions into metrics. There are several dimensions that can serve as quality standards for the software product. These include the application's features, reliability, usability, performance, response, conformance, aesthetics, and maintainability. Although these dimensions focus on the application system, other dimensions can be identified for each of the project deliverables (e.g., business case, project charter and baseline project plan, project reporting, user documentation, etc.). Metrics are vital for gauging quality by establishing tolerance limits and identifying defects **Capability Maturity Model Integrated (CMMI)** Defines 5 levels of systematically more mature processes. Lets take a look at each of these levels. *Level 1: Initial* Characterized by an immature organization in which the project process is ad hoc and often reactive to crises. Does not have a stable environment for projects, and success of a project rests largely with the people on the project and not the processes that they follow. *Level 2: Repeatable* Basic policies, processes, and controls for managing a software project are in place. Previous project successes can be repeated by other project teams on other projects. The key process areas are: - Software Configuration Management - Software Quality Assurance - Software Subcontract Management - Software Project Tracking and Oversight - Software Project Planning - Requirements Management *Level 3: Defined* Software engineering and management processes are documented and standardized throughout the organization and become the organizations standard process. The key process areas are: - Peer Reviews - Intergroup Coordination - Software Product Engineering - Integrated Software Management - Training Programs - Organization Process Definition - Organization Process Focus *Level 4: Managed* Quantitative metrics for measuring and assessing productivity and quality are established for both software products and processes which are characterized as being quantifiable and predictable. The key process areas are: - Software Quality Management - Quantitative Process Management *Level 5: Optimizing* The highest level of software process maturity, the whole organization is focused on continuous process improvement. The key process areas are: - Process Change Management - Technology Change Management - Defect Prevention **Project Quality Management Plan** A Project Quality plan should support the organization in searching for ways to build a better product or system. The Project Quality Management Plan outlines the acceptable level of quality (typically defined by the customer), and describes how the project will ensure this level of quality in its deliverables and work processes. All correspondin activities should ensure that: - Products are built to meet agreed- upon standards and requirements - Work processes are performed efficiently and as documented - Non-conformances found are identified and appropriate corrective action is taken The figure below provides an illustration of the framework that supports a plan development. **Quality Philosophies and Principles** A quality is everyone's responsibility where the key stones are a strong focus on customer satisfaction, prevention instead of inspection, process improvement (improve the process to improve the product (project's deliverables) and requires a fact-based management. **Quality Standards, Processes and Metrics** Standards are documented agreements, protocols, or rules that outline the technical specifications or criteria to be used to ensure that products, services, processes, and materials meet their intended purpose. They are also provide a basis for measurement because they provide criterion, or basis, for comparison. In order to provide an information system that has to ability to interface with other systems and in order to coordinate hardware and software and network compatibility, information systems must conform to the relevant protocols that make up industry standards. A process metric is a measurement of the defects introduced by the processes required to develop or create the product deliverables. Example would include such metrics as a defect arrival rate, defects by phase, defect backlog, fix response time, and defective fixes. Metrics that attempt to describe the intrinsic quality and characteristics of the project's deliverables and final product are called product metrics. Examples would include mean time to failure, defect density, customer found defects, and customer satisfaction. Metrics that measure the control of project processes and which are used to determine whether the software product and project deliverables meet requirements for "fitness for use" and "conformance to requirements" as defined by the internal or external customers are called project metrics. Examples include: Scope change requests, Scope change approvals, Overdue tasks, Tasks that should have started, Over budgeted tasks, Earned value, Over allocated resources, Turnover, and Training hours. **Quality Assurance** Provides the basis for continuous improvement by auditing and evaluating the results from quality control measurements so that appropriate quality standards and operational definitions are used. Testing is a basis for ensuring that the product or system functions as intended and has all the capabilities and features defined in the project's scope document. An undesirable behavior associated with the product or process called defect (Ginac 1998). It is a failure to comply with a requirement (Lewis 2000). In software development, defects are often referred to as bugs. A program that caused a computer system to crash when it ran would be said to have a bug. There are verification and validation activities as per project deliverables type. Verification focuses on the process-related activities of the project to ensure that the product or deliverable meets its specified requirements before final testing of the system begins. Verification requires that the standards and metrics be defined clearly. Moreover, verification activities focus on asking the question of whether we followed the right procedures and processes. Verification is supported by three types of reviews: Technical, Business, and Management. A technical review ensures that the IT solution will conform to the specified requirements. This review may include conformance to graphical user interface (GUI) standards, programming and documentation standards, naming conventions, and so forth. Two common approaches to technical reviews include structured walkthroughs and inspections. A business review is designed to ensure that the IT solution provides the required functionality specified in the project scope and requirements definition. A management review basically compares the project's actual progress against the baseline project plan. In general, the project manager is responsible for presenting the project's progress to provide a clear idea of the project's current status. Issues may need to be resolved, resources adjusted, or decisions made to either stay or alter the project's course. In addition, management may review the project to determine if it meets the scope, schedule, budget, and quality objectives. Validation is a product-oriented activity that attempts to determine if the system or project deliverable meets the customer or client's expectations and ensures that the system performs as specified. Validation is supported primarily by testing using one or more of several approaches: Unit, Integration, Systems, and/or Acceptance Testing. **Quality Control** Monitoring and documenting the results of executing project quality activities to eliminate causes of unsatisfactory performance and implement new processes and techniques to improve project quality throughout the organization. Control Charts are a product-oriented activity that attempts to determine if the system or project deliverable meets the customer or client's. It provides a picture of how a particular process is behaving over time. All control charts have a centerline and control limits on either side of the centerline. Examples are below. The centerline represents the observed average, while the control limits on either side provide a measure of variability. In general, control limits are set at ±3\_ (i.e., ±3 sigma) or ±3s, where \_ represents the population standard deviation and s represents the sample standard deviation. If a process is normally distributed, control limits based on three standard deviations provides.001 probability limits. Variation attributed to common causes is considered normal variation and exists as a result of normal interactions among the various components of the process---i.e., chance causes. These components include people, machines, material, environment, and methods. As a result, common cause variation will remain stable and exhibit a consistent pattern over time. This type of variation will be random and vary within predictable bounds. If all observations fall within the control limits and the variation pattern is random, the process is said to be in statistical control. When one of the following conditions is observed, the process may be exhibiting nonrandom behavior and be out of statistical control: - A single point falls outside of the 3σ control limit - At least two of three successive values fall on the same side of and more than two standard deviations from the centerline - At least four out of five successive values fall on the same side of and more than one standard deviation away from the centerline. - At least eight successive values that fall on the same side of the centerline **Cause and Effect Diagrams** The fishbone, or Ishikawa, diagram developed by Kaoru Ishikawa was developed to analyze the causes of poor quality in manufacturing systems. The diagram can be used for understanding the causes or factors of a particular quality characteristic or problem. A particular quality characteristic or problem is represented by targeted box and then the major causes are identified and linked to the subject of study. Each major cause then is further subdivided into potential sub-causes. This approach is often deployed by using either brainstorming or learning cycle approaches. Once the diagram is completed, the project team can investigate the posited causes and recommend solutions to address the problem. **Pareto Chart** A Pareto Chart is based on the 80/20 rule that infers that 80% of effects flow from 20% of the causes. The diagram is essentially a chart that rank orders the most important problem causes from left to right in descending order of magnitude. In this way the most import problem areas are highlighted and which, when appropriately addressed, offer the greatest improvement to the product or process. **Additional Quality Controls** The figure below shows some additional quality control tools used, for example flow charts (or sometimes called process maps) - a graphical representation of the logical progression of a product or service from one process or procedure to the next. Flow charts can be useful for documenting a specific process in order to understand how products or services move through various functions or operations. A flow chart can help visualize a particular process and identify potential problems or bottlenecks. Standardized symbols can be used, but are not necessary. It is more important to be able to identify problems or bottlenecks, reduce complexity, and determine who is the next customer.