Pmp quality management

In this file, you can ref useful information about pmp quality management such as pmp quality
managementforms, tools for pmp quality management, pmp quality managementstrategies If
you need more assistant for pmp quality management, please leave your comment at the end of
file.
Other useful material for pmp quality management:
qualitymanagement123.com/23-free-ebooks-for-quality-management
qualitymanagement123.com/185-free-quality-management-forms
qualitymanagement123.com/free-98-ISO-9001-templates-and-forms
qualitymanagement123.com/top-84-quality-management-KPIs
qualitymanagement123.com/top-18-quality-management-job-descriptions
qualitymanagement123.com/86-quality-management-interview-questions-and-answers

I. Contents of pmp quality management

==================

Okay it has been a while since my last installment in this series. Aside from my general
inability to stay focused on a single topic (what was I thinking committing to a nine part
series) I got really swamped preparing for Agile 2008. Ive got two talks coming up in
November on this material, one of which has a presentation due in early September, so I
guess it is time to get busy and get this series wrapped up.
Last time we covered Communications Management, in this post well discuss Quality
Management.
As always, lets start with the PMI definition of Quality Management. According to PMI,
Project Quality Management includes all the activities of the performing organization to
determine quality policies, objectives, and responsibilities so that the project will satisfy the
needs for which it was undertaken. There are three processes included in this knowledge area:
quality planning, perform quality assurance, and perform quality control.
If youve been following this series, youll know that my general approach with the PMI is to
take guidance from the PMBOK and figure out how to satisfy the intent of the process with a

more agile practice or principle. Agile is all over quality planning, quality assurance, and
quality control but we often use different language to describe how we satisfy these
objectives and we often plan for these activities in a pretty different way.
Lets see what we can do to bridge the gap
Quality Planning
PMI Definition: Identifying which quality standards are relevant to the project and
determining how to satisfy them
Quality planning is really about the initial set of assumptions (we make as an agile team)
about how we are going to manage quality on our projects. As it relates to developing
software, quality planning has mostly been done for us it is implicit it is understood by
virtue of the fact that we are using an agile methodology.
When we have discussions about doing test driven development, pair programming, or
continuous integration; we are making decisions about how we are going to handle quality.
The decision to make use of acceptance criteria is simply a decision on how we will know we
have met the requirements of our stakeholders.
Are we going to do unit testing? How about manual regression? Will we need to test for
performance, scalability, or security? How will we know we have met any applicable
regulatory or audit requirements? I would venture to say that most agile teams are having
these conversations. Even if your team is not writing this stuff down or getting sign-off, you
are implicitly developing your quality plan.
It is up to the team to balance how much of this needs to be documented. Ask yourself to
what degree will a document facilitate understanding or help with stakeholder
communication? Consider how much documentation is required by your organization. Keep
things simple, minimally prescriptive, and make provisions to adapt your plan as you learn
more about the emerging solution.
Perform Quality Assurance

PMI Definition: Applying the planned, systematic quality activities to ensure that the project
employs all processes needed to meet the requirements
Youve made some initial decisions about how your team will meet the quality expectations
of the organization now it is time to execute. Quality assurance is about making sure we
are building the right product from the very beginning.
Early in the iteration, we meet as a team with our customers to define exactly what is to be
built. Every role on the project has the opportunity and is encouraged to be involved. There
are people looking at the requirements from every conceivable angle: system architecture,
development, QA, analysis and design, and usability. We explore the problem from all
perspectives, before we set off writing code, to ensure we are building a complete product.
Once we get started building out the features, we immediately execute our testing plans. At a
minimum, agile teams are writing unit tests and doing continuous integration. We know at
every moment of the project how well the code is performing against the requirements.
If your team has dedicated QA members, the QA folks are testing right along with the
development team. Sometimes it is more exploratory and we are not looking for sign-off, we
are really looking for feedback. Feedback from the QA team is essential to making sure that
the product is evolving according to the quality standards we agreed to at the beginning of the
iteration.
The team holds itself accountable by meeting in a daily standup. This allows the team to stay
plugged in, assess progress, and identify impediments. In addition, the team has constant
access to the product owners. This constant visibility allows the customer to fine tune the
solution, as it is being built, to ensure that the product will meet market requirements.
Perform Quality Control
PMI Definition: Monitoring the specific project results to determine whether they comply
with relevant quality standards and identifying ways to eliminate causes of unsatisfactory
performance.
Even though quality is the focus from the very beginning in an agile project, we still seek to
validate outcomes and formally track the quality of the product we are building.

The advantage of automated testing is that we know the health of the product in real time. We
are able to measure and track defects and get them resolved as soon as they are introduced
into the build. Manual testing, in parallel with the automated testing, gives a more intuitive
way to exercise aspects of the code the are difficult to automate.
As a project manager I am constantly tracking burndown at the project level to see how well
the team is doing against the backlog. Within the iteration, I am tracking task progress to
make sure that we can deliver on our commitments. Agile teams also track defects, defect
status, and test trends. All this gives the team a way to continuously control the project
quality.
Agile teams dont wait until the end of the project to test, when we have the least amount of
time to actually fix a problem, or respond to a change. We know at all times the health of the
project, if the team is burning hot, if defects counts are trending up or down, how well we are
resolving issues, and if those issues are becoming impediments to getting new product built.
Agile teams review features with their customer as they are completed. They do formal
product demonstrations and retrospectives at the end of every iteration. These processes
allow the team to control, not only the quality of the emerging product, but also of the
processes we are using to deliver that product.
All of this feedback gets folded back into the plan, adjustments are made, and the team adapts
based on what they have learned from regularly delivering code.
Next up Procurement and Human Resources. Well save Risk Management and Integration
Management for last!
==================

III. Quality management tools

1. Check sheet

The check sheet is a form (document) used to collect data

in real time at the location where the data is generated.
The data it captures can be quantitative or qualitative.
When the information is quantitative, the check sheet is
sometimes called a tally sheet.
The defining characteristic of a check sheet is that data
are recorded by making marks ("checks") on it. A typical
check sheet is divided into regions, and marks made in
different regions have different significance. Data are
read by observing the location and number of marks on
the sheet.
Check sheets typically employ a heading that answers the
Five Ws:

Who filled out the check sheet

What was collected (what each check represents,
an identifying batch or lot number)
Where the collection took place (facility, room,
apparatus)
When the collection took place (hour, shift, day of
the week)
Why the data were collected

2. Control chart
Control charts, also known as Shewhart charts
(after Walter A. Shewhart) or process-behavior
charts, in statistical process control are tools used
to determine if a manufacturing or business
process is in a state of statistical control.
If analysis of the control chart indicates that the
process is currently under control (i.e., is stable,
with variation only coming from sources common
to the process), then no corrections or changes to
process control parameters are needed or desired.

In addition, data from the process can be used to

predict the future performance of the process. If
the chart indicates that the monitored process is
not in control, analysis of the chart can help
determine the sources of variation, as this will
result in degraded process performance.[1] A
process that is stable but operating outside of
desired (specification) limits (e.g., scrap rates
may be in statistical control but above desired
limits) needs to be improved through a deliberate
effort to understand the causes of current
performance and fundamentally improve the
process.
The control chart is one of the seven basic tools of
quality control.[3] Typically control charts are
used for time-series data, though they can be used
for data that have logical comparability (i.e. you
want to compare samples that were taken all at
the same time, or the performance of different
individuals), however the type of chart used to do
this requires consideration.

3. Pareto chart

A Pareto chart, named after Vilfredo Pareto, is a type

of chart that contains both bars and a line graph, where
individual values are represented in descending order
by bars, and the cumulative total is represented by the
line.
The left vertical axis is the frequency of occurrence,
but it can alternatively represent cost or another
important unit of measure. The right vertical axis is
the cumulative percentage of the total number of
occurrences, total cost, or total of the particular unit of
measure. Because the reasons are in decreasing order,
the cumulative function is a concave function. To take
the example above, in order to lower the amount of
late arrivals by 78%, it is sufficient to solve the first
three issues.
The purpose of the Pareto chart is to highlight the
most important among a (typically large) set of
factors. In quality control, it often represents the most
common sources of defects, the highest occurring type
of defect, or the most frequent reasons for customer
complaints, and so on. Wilkinson (2006) devised an
algorithm for producing statistically based acceptance
limits (similar to confidence intervals) for each bar in
the Pareto chart.

4. Scatter plot Method

A scatter plot, scatterplot, or scattergraph is a type of

mathematical diagram using Cartesian coordinates to
display values for two variables for a set of data.
The data is displayed as a collection of points, each
having the value of one variable determining the position
on the horizontal axis and the value of the other variable
determining the position on the vertical axis.[2] This kind
of plot is also called a scatter chart, scattergram, scatter
diagram,[3] or scatter graph.
A scatter plot is used when a variable exists that is under
the control of the experimenter. If a parameter exists that
is systematically incremented and/or decremented by the
other, it is called the control parameter or independent
variable and is customarily plotted along the horizontal
axis. The measured or dependent variable is customarily
plotted along the vertical axis. If no dependent variable
exists, either type of variable can be plotted on either axis
and a scatter plot will illustrate only the degree of
correlation (not causation) between two variables.
A scatter plot can suggest various kinds of correlations
between variables with a certain confidence interval. For
example, weight and height, weight would be on x axis
and height would be on the y axis. Correlations may be
positive (rising), negative (falling), or null (uncorrelated).
If the pattern of dots slopes from lower left to upper right,
it suggests a positive correlation between the variables
being studied. If the pattern of dots slopes from upper left
to lower right, it suggests a negative correlation. A line of
best fit (alternatively called 'trendline') can be drawn in
order to study the correlation between the variables. An
equation for the correlation between the variables can be
determined by established best-fit procedures. For a linear
correlation, the best-fit procedure is known as linear
regression and is guaranteed to generate a correct solution
in a finite time. No universal best-fit procedure is
guaranteed to generate a correct solution for arbitrary
relationships. A scatter plot is also very useful when we
wish to see how two comparable data sets agree with each

other. In this case, an identity line, i.e., a y=x line, or an

1:1 line, is often drawn as a reference. The more the two
data sets agree, the more the scatters tend to concentrate in
the vicinity of the identity line; if the two data sets are
numerically identical, the scatters fall on the identity line
exactly.

5.Ishikawa diagram
Ishikawa diagrams (also called fishbone diagrams,
herringbone diagrams, cause-and-effect diagrams, or
Fishikawa) are causal diagrams created by Kaoru
Ishikawa (1968) that show the causes of a specific event.
[1][2] Common uses of the Ishikawa diagram are product
design and quality defect prevention, to identify potential
factors causing an overall effect. Each cause or reason for
imperfection is a source of variation. Causes are usually
grouped into major categories to identify these sources of
variation. The categories typically include
People: Anyone involved with the process
Methods: How the process is performed and the
specific requirements for doing it, such as policies,
procedures, rules, regulations and laws
Machines: Any equipment, computers, tools, etc.
required to accomplish the job
Materials: Raw materials, parts, pens, paper, etc.
used to produce the final product
Measurements: Data generated from the process
that are used to evaluate its quality
Environment: The conditions, such as location,
time, temperature, and culture in which the process
operates

6. Histogram method

A histogram is a graphical representation of the

distribution of data. It is an estimate of the probability
distribution of a continuous variable (quantitative
variable) and was first introduced by Karl Pearson.[1] To
construct a histogram, the first step is to "bin" the range of
values -- that is, divide the entire range of values into a
series of small intervals -- and then count how many
values fall into each interval. A rectangle is drawn with
height proportional to the count and width equal to the bin
size, so that rectangles abut each other. A histogram may
also be normalized displaying relative frequencies. It then
shows the proportion of cases that fall into each of several
categories, with the sum of the heights equaling 1. The
bins are usually specified as consecutive, non-overlapping
intervals of a variable. The bins (intervals) must be
adjacent, and usually equal size.[2] The rectangles of a
histogram are drawn so that they touch each other to
indicate that the original variable is continuous.[3]

III. Other topics related to Pmp quality management (pdf

download)
quality management systems
quality management courses
quality management tools
iso 9001 quality management system
quality management process
quality management system example
quality system management
quality management techniques
quality management standards
quality management policy
quality management strategy
quality management books