IT Project Management Individual Assignment
IT Project Management
version 1.0
Diploma in Information Technology
Copyright © 2020 by Singapore Institute of Management Pte Ltd. All rights reserved.
Lesson 16: Project Quality Management –
Part 2
1
Learning objectives
Understand the tools and techniques for quality control, such as the Seven Basic Tools of Quality, Statistical Sampling, Six Sigma, and Testing
Describe how leadership, the cost of quality, organisational influences, expectations, cultural differences, and maturity models relate to improving quality in IT projects
Discuss how software can assist in project quality management
2
16.1 Quality Control 7 Tools
Check Sheet
Scatter Diagram
Cause-and-Effect Diagram
Pareto Chart
Flow Chart
Histogram
Statistical Process Control (SPC) Chart
3
16.1.1 Check Sheet
It is used to easily collect data. Decision-making and actions are taken from the data.
4
16.1.2 Scatter Diagram
It is a graphical tool that plots many data points and shows a pattern of correlation between two variables.
5
16.1.3 Cause-and-Effect Diagram
It is used to figure out any possible causes of a problem. After the major causes are known, we can solve the problem accurately
6
16.1.4 Pareto Chart
It is used to define problems, to set their priority, to illustrate the problems detected, and determine their frequency in the process.
7
16.1.5 Flow Chart
It shows the process step by step.
8
16.1.6 Histogram
It shows a bar chart of accumulated data and provides the easiest way to evaluate the distribution of data.
9
16.1.7 Statistical Process Control Chart
10
Upper Control Limit
Lower Control Limit
Mean
16.1.7 Statistical Process Control Chart
11
It provides control limits which are generally three standard deviations above and below average, whether or not a process is in control.
Upper control limit
Average value
Lower control limit
Time
3
3
16.1.7 Statistical Process Control Chart
12
Control charts attempt to distinguish between two types of process variation:
Common cause variation: which is intrinsic to the process and will always be present.
Special cause variation: which stems from external sources and indicates that the process is out of statistical control.
16.1.7 Statistical Process Control Chart
13
The above process is in control, all data points are within the control limits.
16.1.7 Statistical Process Control Chart
14
The 2 points marked by “X” are out of control.
16.1.7 Statistical Process Control Chart
15
How to Implement Quality Project Management
Quality Control
Every process needs a policeman, so to speak, to make sure that the rules are being following and that the expected quality is being met. Some ways to ensure that the required quality of the deliverables is being achieved is through peer reviews and testing.
c
16
16.2 Six Sigma
Six Sigma is a highly disciplined process that helps firms to focus on developing and delivering near-perfect products and services.
Six Sigma ‘s target for perfection is the achievement of no more than 3.4 defects, errors, or mistakes per million opportunities (DPMO)
An "opportunity" is defined as a chance for non-conformance, or not meeting the required specifications.
16.2 Six Sigma
18
Mean
Lower limits
Upper limits
3.4 defects/million
99.99966% capable
±6
2,700 defects/million
99.73% capable
±3
+6σ
-6σ
16.2 Six Sigma
99.73% => 0.27% defects
= 0.27 / 100
[x 10000]
= 2700/1,000,000
=>2700 DPMO
99.99966% => 0.00034% defects
= 0.00034 / 100
[x 10000]
= 3.4/1,000,000
=>3.4 DPMO
16.2 Six Sigma
Projects that use Six Sigma principles for quality control normally follow a five-phase improvement process called DMAIC (pronounced de-MAY-ick), which stands for Define, Measure, Analyse, Improve, and Control.
16.2 Six Sigma
21
16.2 Six Sigma
22
How Is Six Sigma Quality Control Unique?
How does using Six Sigma principles differ from using previous quality control initiatives?
Many people remember other quality initiatives from the past few decades such as Total Quality Management (TQM) and Business Process Reengineering (BPR)
ANSWER: Using Six Sigma principles is an organization-wide commitment.
23
16.3 Testing of IT software
A unit test is done to test each individual component (often a program) to ensure that it is as defect-free as possible. Unit tests are performed before moving onto the integration test.
Integration testing occurs between unit and system testing to test functionally grouped components. It ensures a subset(s) of the entire system works together.
24
System testing tests the entire system as one entity. It focuses on the big picture to ensure that the entire system is working properly.
User acceptance testing is an independent test performed by end users prior to accepting the delivered system. It focuses on the business fit of the system to the organisation, rather than technical issues.
16.3 Testing of IT software
25
Watts S. Humphrey, a renowned expert on software quality, defines a software defects as anything that must be fixed before delivery of the program.
Testing does not sufficiently prevent software defects because:
There are many ways to test a complex system.
Users will continue to invent new ways to use a system that its developers never considered.
16.3 Testing of IT software
26
Humphrey suggests that people rethink the software development process to provide no potential defects when entering the system testing phase; developers must be responsible for providing error-free code at each stage of testing.
16.3 Testing of IT software
27
16.4 Improving IT Project Quality
Suggestions:
Establish leadership that promotes quality
Understand the cost of quality
Focus on organisational influences and workplace factors that affect quality
Follow maturity models
28
16.4.1 Leadership
“It is almost important that top management be quality-minded. In the absence of sincere manifestation of interest at the top, little will happen below”
Joseph Juran
In fact, a large percentage of quality problems are associated with management, not technical issues.
29
Quality doesn’t come free.
The Cost of Quality (COQ) is the money spent dealing with issues during the project, and then after the project, to fix any failures.
16.4.2 Cost of Quality
c
30
16.4.2 Cost of Quality
The cost of quality is the cost of conformance plus the cost of non-conformance.
Conformance – Delivering products or services that meet requirements and fitness for use.
Non-conformance – Taking responsibility for failures or not meeting quality expectations
31
16.4.2 Cost of Quality
16.4.2 Cost of Quality
Cost of conformance
Prevention cost – Cost of planning and executing a project so it is error-free or within an acceptable error range. Example: training, quality planning, process studies etc.
Appraisal cost – Cost of evaluating processes and their outputs to ensure quality. Example: testing, destructive testing loss and inspections.
33
16.4.2 Cost of Quality
Cost of non-conformance
Internal failure cost – Cost incurred to correct an identified defect before the customer receives the product. Example: rework and scrap, corrective actions etc.
External failure cost – Cost that relates to all defects and problems after the customer has received the product. Example: Returned goods, customer complaint, warranty etc.
34
16.4.3 Organisational Influences, Workplace Factors and Quality
Study by Demarco and Lister showed that organizational issues had a much greater influence on programmer productivity than the technical environment or programming languages.
Programmer productivity varied by 100 to 1000% across organisations, but only by 21% within the same organisation.
35
16.4.3 Organisational Influences, Workplace Factors and Quality
Study found no correlation between productivity and programming language, years of experience or salary.
A dedicated workspace and a quiet work environment were key factors to improving programmer productivity.
36
16.4.4 Expectations and Cultural Differences in Quality
Project managers need to understand and manage the stakeholder expectations.
Expectations also vary by:
Organisation’s culture
Geographic regions
37
16.4.4 Expectations and Cultural Differences in Quality
38
16.4.5 Maturity Models
Maturity models are frameworks for helping organisations improve their processes and systems.
The Software Quality Function Deployment Model focuses on defining user requirements and planning software projects.
39
16.4.5 Maturity Models
Quality function deployment (QFD) is a process used to determine product development characteristics that combine technical requirements with customer preferences.
It is done using an integrated matrix known as the “house of quality”.
40
16.4.5 Maturity Models
House of quality template
41
16.4.5 Maturity Models
House of quality example
42
16.4.6 PMI’s Maturity Model
PMI Maturity Model is based on market research surveys sent to more than 30,000 project management professionals and incorporates 180 best practices and more than 2,400 capabilities, outcomes and key performance indicators.
Addresses standards for excellence in project, program and portfolio management best practices and explains the capabilities necessary to achieve those best practices
43
15.9 Using Software to Assist in Project Quality Management
PM software helps to create Gantt charts and other tools to plan and track work related to quality management.
Spreadsheet and charting software helps create Pareto charts, cause and effects diagrams etc.
44
15.9 Using Software to Assist in Project Quality Management
Specialised software help manage Six Sigma projects or create quality control charts.
Statistical software packages help to perform statistical analysis.
45
15.9 Using Software to Assist in Project Quality Management
Bug tracking software: A software where bugs are reported, tracked, and then resolved.
Automated testing software: While there is no substitute to human testing to ensure a very stable end product, automated testing can weed out the most common bugs and will make the human testing less stressful.
46
15.9 Using Software to Assist in Project Quality Management
Collaboration software:
The project manager and team members use to exchange information about the project.
Team members can ask for help from other team members when facing challenges on their tasks.
Team members building upon code that is written by other team members can inform the latter about errors in their codes.
Testers can inform developers about their bugs.
47