Information

Technology Project
Management
by Jack T. Marchewka

Power Point Slides by Jack T. Marchewka, Northern Illinois University

Copyright 2006 John Wiley & Sons, Inc. all rights reserved. Reproduction or translation of this work beyond that permitted
in Section 117 of the 1976 United States Copyright Act without the express permission of the copyright owner is unlawful.
Request for further information information should be addressed to the Permissions Department, John Wiley & Sons, Inc.
The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher
assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the
information contained herein.
 Chapter 10
IT Project Quality Management
 Learning Objectives
Describe the Project Management Body of Knowledge
(PMBOK) area called project quality management (PQM) and
how it supports quality planning, quality assurance, quality
control, and continuous improvement of the projects products
and supporting processes.
Identify several quality gurus, or founders of the quality
movement, and their role in shaping quality philosophies
worldwide.
Describe some of the more common quality initiatives and
management systems that include ISO certification, Six Sigma,
and the Capability Maturity Model (CMM) for software
engineering.
Distinguish between validation and verification activities and how
these activities support IT project quality management.
Describe the software engineering discipline called configuration
management and how it is used to manage the changes
associated with all of the projects deliverables and work products.
Apply the quality concepts, methods, and tools introduced in this
chapter to develop a project quality plan.
 Quality
an inherent or distinguishing
characteristic; a property; having a high
degree of excellence
Features & functionality
Grade is not quality!
fitness for use
conformance to requirements
 63,000 known bugs in Windows
2000?
In February 2000, a Microsoft Corp memo
caused quite a stir when it was leaked to
the public. An excerpt from that memo
reads
Our customers do not want us to sell them products with over
63,000 potential defects. They want those defects corrected.
How many of you would spend $500 on a piece of software with
over 63,000 potential known defects?
 Uniform Computer Information
Transactions Act (UCITA)
A software vendor could legally disclaim any
obligation to sell products that work.
In the event of a dispute, a software vendor could
disable a customers software remotely even if it
totally disrupted the customers business.
Security experts would be prohibited from reverse
engineering software in order to examine it for
defects and viruses.
A software vendor could legally stop a user from
making public comments on the quality or
performance of a product.
 Project Quality Management
(PQM) - PMBOK
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.
 PMBOK Project Quality
Management Process
Quality Planning
Determining which quality standards are
important and how they will be met.
Quality Assurance
Evaluating overall project performance to
ensure quality standards are being met.
Quality Control
Monitoring the activities and results of the
project to ensure that the project complies with
the quality standards.
 PQM Focuses on
The projects products
Business Case
Project Plan
The IT Solution
Etc.
And the projects processes
Scope management
Risk management
Requirements Analysis
Design
Implementation
Etc.
 The Quality Chain

More efficient & effective use of resources More rework, waste, & errors
Minimize errors Negative impact on project goal &
Meet or exceed stakeholder expectations objectives
Poor quality can be an embarrassment!

Project and IT development processes support the projects products

Customers may be internal or external
 Project Quality Management

Figure 10.1
 The Quality Movement
Early humankind
Quality = Survival
Craftsmanship
In the middle ages guilds regulated:
Who could sell what in a particular town
Ensured standardized pricing and quality
Supported members & their families when members could no
longer work
Regulated forms of labor
Masters owned the shop
Apprentices were bound to a master & learned the trade
Journeymen completed training & waited for a job opening!
 The Quality Movement
The Industrial Revolution
Eli Whitney (1765 1825)
Invented the cotton gin
But also invented mass production
In 1798 received $134,000 from the US Government to deliver
10,000 rifles within 2 years
Shortage of gunsmiths
Developed the manufactory where machines could build
interchangeable parts and men could learn to operate the
machines
Took 10 years to deliver the last rifle, but proved that the
concept worked!
 The Quality Movement

Scientific Management - Fredrick W. Taylor (1856

1915)
Management would set arbitrary rules of thumb
Workers produced so much each day no more, no less
Believed the production process could be more efficient and
employed Scientific Management
Break a task down into smaller tasks & study it to find the best and
most efficient way of doing it
Time motion studies using stopwatch
Did not sit well with labor unions because many ignored the
human factors & believed profits could be increased by
speeding up the workers
 The Quality Movement
Walter A. Shewhart (1891 1967)
Worked for Western Electric Company (Bell
Telephones
Quality improvements needed for
underground equipment
Applied statistical theory to control production
processes
 Control Chart for a Control Chart for a
Process within Statistical Process Not in Statistical
Control Control

Figure 10.2
 The Quality Movement
The Rise of Japan
W. Edwards Deming (1900 1993)
Worked with Shewhart at Western Electric Hawthorne Plant
in Chicago, IL in the 1920s
Management treated the worker as a cog in the machinery
Final inspection used to control quality
Worker not directly responsible
Scrap & rework reduced per piece rate
Invited to give series of day-long lectures in Japan in the
1950s
The rest is history
 Demings 14 Points
1. Have a purpose (improve products and services, be competitive, stay in business,
and provide jobs).
2. Adopt the new philosophy of management..
3. Dont depend on inspection at the end.
4. Dont award business based on price alone of price.
5. Keep improving constantly.
6. Institute training on the job.
7. Institute leadership
8. Drive out fear.
9. Break down barriers between departments.
10. Eliminate slogans.
11. a) Eliminate quotas
b) Eliminate management by objective and by numbers.
12. Take pride in your work.
13. Focus education and self-improvement.
14. It takes everyone to accomplish the transformation.
From Out of the Crisis by W. Edwards Deming (1986)
 The Quality Movement

The Rise of Japan continued

Joseph Juran (1904 - )
Viewed quality as fitness for use
Also invited to Japan to conduct seminars in
the 1950s
Message is that quality does not happen by
accident it must be planned.
 The Quality Movement
Jurans Quality Planning Road Map (Quality Trilogy)
Quality Planning
1. Identify who the customers are.
2. Determine the needs of those customers.
3. Translate those needs into our language.
4. Develop a product that can respond to those needs.
5. Optimize the product features so as to meet our needs as well as
customer needs.
Quality Improvement
6. Develop a process that is able to produce the product.
7. Optimize the process.
Quality Control
8. Prove that the process can produce the product under operating
conditions.
9. Transfer the process to Operations.
 The Quality Movement
The Rise of Japan continued
Kaoru Ishikawa (1915 - 1989)
Studied under Deming
Believes quality is a continuous process that
relies on all levels of the organization
Advocated the use of easy-to-use statistical
tools
Ishikawa, or Fishbone Diagram
Pareto Diagram
Flow Charts
 Ishikawa, or Fishbone
Diagram

Figure 10.4
 Pareto Chart

Figure 10.5
Flow Chart for
Project Scope
Verification

Figure 10.6
 The Quality Movement
Philip Crosby (1926 2001)
Advocated
Do it right the first time
Zero defects
Quality is free
Non-conformance costs organizations money
 Quality Systems
International Organization for
Standardization (ISO)
Derived from Greek word isos, meaning equal
Formed in 1947
Today has over 130 members to facilitate the
international coordination and unification of
industrial standards.
Standards make up the ISO 9000
(organizations) and ISO 14000 (environmental)
families
 Quality Systems
ISO 9000 Principles
Customer Focus
Leadership
Involvement of People
Process Approach
System Approach to Management
Continual Improvement
Factual Approach to Decision Making
Mutually Beneficial Supplier Relationships
 Quality Systems
6 Sigma
Six Sigma framework (D-M-A-I-C cycle)
Define
Measure
Analyze
Improve
Control
 Quality Systems
6 Sigma
Originated by Motorola in Schaumburg, IL
Based on competitive pressures in 1980s
Our quality stinks
Sigm Defects Per 3 6
a Million
Five short or long landings at any One short or long landing in 10
1 690,000 major airport years at all airports in the US
2 308,537
Approximately 1,350 poorly One incorrect surgical operation in
3 66,807 performed surgical operations in 20 years
one week
4 6,210
Over 40,500 newborn babies Three newborn babies dropped by
dropped by doctors or nurses each doctors or nurses in 100 years
5 233
year
6 3.4 Drinking water unsafe to drink for Water unsafe to drink for one
about 2 hours each month second every six years
 Six Sigma Programs
Master Black Belts
Have the highest level of technical and organizational
experience and expertise who train Six Sigma Black Belts
Black Belts
Come from various disciplines, have a high degree of
experience and expertise and are held in high esteem
Green Belts
Six Sigma leaders or project managers
Champions
An added role in many organizations. They are leaders who are
committed to the success of the Six Sigma project, provide
funding, and can ensure organizational barriers and obstacles
are removed
 Quality Systems
TickIT
Quality initiative initiated by the British Computer
Society (BCS) in 1991
Software organizations were reluctant to adopt
ISO 9000 standards
Too general & too difficult
TickIT guides a company through ISO
certification by an independent certification body
TickIT gives software developers an accredited
quality certification specialized for software
organizations to increase the confidence of
customers and suppliers
 Quality Systems
The Capability Maturity Model Integration
(CMMI)
Software Engineering Institute (SEI) at
Carnegie-Mellon University
Includes a set of recommended practices for a
set of key process areas specific to software
development.
Provide guidance as to how an organization can
best control its processes for developing and
maintaining software.
Provide a path for helping organizations evolve
their current software processes toward software
engineering and management excellence
 CMMI
Software Process
The logical organization of people, materials, energy, equipment,
and procedures into work activities to produce a specified end result
Software Process Capability
The expected results that can be achieved by following a particular
software process that can be used to predict the outcome if a
software process is followed
Software Process Performance
The actual results achieved when a particular software process is
followed so that actual performance can be compared to expected
results
Software Process Maturity
The extent to which a particular software process is explicitly and
consistently defined, managed, measured, controlled, and effectively
used
 Quality Systems
CMMI

Immature Software Organization

Reactive in nature - Managers continually fight fires
Schedules & budgets are usually exceeded
Functionality & quality often compromised to meet
schedules
Project success determined by who is or is not part of
the project team
No basis for judging quality
Never seems to be enough time to address problem
issues or improve the current processes
 Quality Systems
CMMI
Mature Software Organization
Proactive and able to follow a set of disciplined processes
throughout the software project.
Software processes and the roles of individuals are defined
explicitly and communicated throughout the organization.
Software processes are consistent throughout the organization
and continually improved based on experimentation or
experiences.
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.
 Maturity Levels
Maturity levels lay successive foundations
for continuous improvement
Can measure the maturity of an
organizations software process
Can evaluate its software process
capability
Help prioritize improvement efforts
Levels of Software Process
Maturity

Figure 10.7
 Quality Systems
CMMI
Level 1: Initial
Characterized by an immature software
organization in which the software process is
ad hoc and often reactive to crises. Does not
have a stable environment for software
projects, and success of a project rests
largely with the people on the project and not
the processes that they follow.
Key Process Area
no key process areas are in place
 Quality Systems
CMMI
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.
Key Process Area
Software Configuration Management
Software Quality Assurance
Software Subcontract Management
Software Project Tracking and Oversight
Software Project Planning
Requirements Management
 Quality Systems
CMMI
Level 3:
Defined - Software engineering and management processes
are documented and standardized throughout the organization
and become the organizations standard process.
Key Process Area
Peer Reviews
Intergroup Coordination
Software Product Engineering
Integrated Software Management
Training Programs
Organization Process Definition
Organization Process Focus
 Quality Systems
CMMI
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.
Key Process Areas
Software Quality Management
Quantitative Process Management
 Quality Systems
CMMI
Level 5:
Optimizing at the highest level of software process
maturity- the whole organization is focused on
continuous process improvement.
Key Process Areas
Process Change Management
Technology Change Management
Defect Prevention
 The IT Project Quality Plan

Figure 10.8
 The IT Project Quality Plan
Quality Philosophies and Principles
Focus on customer satisfaction
Prevention not inspection
Improve the process to improve the
product
Quality is everyones responsibility
Fact-based management
 The IT Project Quality Plan
Quality Standards and Metrics

Figure 10.9
 Project Quality Metrics
Process
Control the defects introduced by the
processes required to create the project
deliverables
Can be used to improve software
development or maintenance
Should focus on the effectiveness of
identifying and removing defects or bugs
 Project Quality Metrics
Product
Focuses on the intrinsic quality of the
deliverables and satisfaction of the customer,
client, or sponsor with these deliverables
Attempt to describe the characteristics of the
projects deliverables and final product
 Project Quality Metrics
Project
Focus on the control of the project
management processes to ensure that the
project meets its overall goal as well as its
scope, schedule, and budget objectives
Examples of Process, Product, & Project Metrics
Type Metric Description
Process Defect Arrival Rate The number of defects found over a specific period of time.
Defects by Phase The number of defects found during each phase of the project.
Defect Backlog The number of defects waiting to be fixed.
Fix Response Time The average time it takes to fix a defect.
Defective Fixes The number of fixes that created new defects.
Product Mean Time to Failure Average or mean time elapsed until a product fails.
Defect Density The number of defects per lines of code (LOC) or function points.
Customer Found Defects The number of defects found by the customer.
Customer Satisfaction An index to measure customer satisfaction e.g., scale from 1
(very unsatisfied) to 5 (very satisfied)
Project Scope Change Requests The number of scope changes requested by the client or sponsor.
Scope Change Approvals The number of scope changes that were approved.
Overdue tasks The number of tasks that were started but not finished by the
expected date or time.
Tasks that should have started The number of task that should have started but have been
delayed.
Over budgeted tasks The number of tasks (and dollar amount) of tasks that have cost
more to complete than expected
Earned Value Budgeted Cost of Work Performed (BCWP) see Chapter 8.
Over allocated Resources The number of resources assigned to more than one task.
 The IT Project Quality Plan
Verification and Validation
Verification
Focuses on process-related activities to
ensure that the products & deliverables meet
specified requirements before final testing
Are we building the product the right way?
 Verification
Technical Reviews
Ensure that the IT solution will conform to the specified requirements
Walk-throughs are review process where a programmer or developer
walks or leads a group of other programmers or developers through a
program or technical design
Business Reviews
Are designed to ensure that the IT solution provides the required
functionality defined in the project scope and detailed requirements
definition to ensure that a particular project deliverable
Is complete
Provides information necessary for the next phase or process
Meets predefined standards
Conforms to the project (and software development) methodology
Management Reviews
Compares the projects actual progress against the baseline project
plan
Useful for resolving issues or making critical decisions
Usually focuses on the projects scope, schedule, budget, and
quality objectives
 The IT Project Quality Plan
Verification and Validation
Validation focuses on
Product-oriented activities that attempt to determine if the
system or project deliverables meet the customer or
clients expectations
Testing
Does the system function as intended and have all the capabilities
& features defined in the projects scope and requirements
definition?
 Software Testing Approaches
Unit Testing Focuses on the module, program, or object level to determine whether
specific functions work properly.
Black Box Testing Tests the program against specified requirements or
functionality.
White Box Testing Examines paths of logic or the structure inside a
program.
Gray Box Testing Focuses on the internal structure of the program.

Integration Tests whether a set of logically related units (e.g., functions, modules,
Testing programs, etc.) work together properly after unit testing is complete.

Systems Tests the system as a whole in an operating environment to verify

Testing functionality and fitness for use. May include tests to verify usability,
performance, stress, compatibility, and documentation.

Acceptance Certifies that the system satisfies the end user or customers scope and
Testing detailed requirements after systems testing is complete. It is the users or
clients responsibility to assure that all features and functionality are
included so that the projects MOV will be achieved.
 The IT Project Quality Plan
Change Control and Configuration Management

Change is inevitable throughout the

project life cycle
At some point, changes must be managed
What changes were made?
Who made the changes?
When were the changes made?
Why were the changes made?
 The IT Project Quality Plan
Change Control and Configuration Management
Component Identification
Naming conventions
Version Control
Evolutionary changes
Configuration Building
Builds & Releases
Change Control
Proposed changes are evaluated, approved or
rejected, scheduled, and tracked
Reporting & auditing
 Monitor and Control
Quality Control Activities

Figure 10.10

Quality Control Activities should focus on the inputs

and outputs of each process. This can be viewed
in terms of the systems concept.
Quality
Control
Tools
Many of the tools introduced
in this chapter are useful for
monitoring and controlling
the quality control activities
of the project.

Figure 10.11
 Learn, Mature, and Improve
Lessons learned
Provide the basis for continual improvement
Can be the basis for identifying and
implementing best practices

A quality plan should do more that attempt to build a better IT solution,

it should also support the organization in searching for ways to manage
projects better.