Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2

Quality Assurance  Involve customers in the design and

implementation of product, service, and
Quality Manager
process improvements
 Key Responsibilities lies in the following Manage the Quality
areas - Organization/Department
♦ Leadership  Define the mission of the quality
♦ Strategic Planning organization/department, including
♦ Customer Management linking it to the larger organization’s
♦ Supplier Performance mission
♦ Personnel Management  Establish the goals and objectives of the
♦ Training & development quality organization/department
Contribute to the Strategic planning  Manage the budget and resource
and deployment process requirements of the quality
organization/department
 Participate in formulating the
organization’s overall strategic plan  Develop the quality staff, including
selection, evaluation, and professional
 Develop quality strategies to help the
growth
organization to achieve its goals
 Develop and maintain an organizational
focus on the importance of performance Assess Performance Information
excellence  Develop and implement plans to
 Formulate quality-related policies and evaluate the effectiveness of the quality
procedures that support the strategic system
plan  Assess the effectiveness and efficiency
 Collaborate with other departments on of organizational performance
the development of methods for  Design and implement feedback loops
strategic plan deployment throughout to provide performance information to
the organization the organization for continuous
Contribute to the Strategic planning improvement
and deployment process  Use results of assessments to
 Develop and implement performance continuously improve systems and
improvement plans that support processes
organization’s goals, including Develop systems for managing
developing short- and long-term plans supplier performance
and their impact on various
 Develop and implement an overall
stakeholders
supplier management program,
 Identify and obtain the resources including supplier assessments and
necessary for implementing monitoring follow-up actions
performance improvement plans within
 Use supplier performance information to
the context of organizational constraints
continuously improve effectiveness of
 Collaborate on the development and the value chain, including audits,
delivery of training programs for performance data, JIT, dock-to-stock,
improved performance etc.
Develop and Maintain a Customer  Partner with suppliers, including
Focus(Internal & External) information-sharing, involving suppliers
 Use customer expectations as a basis in design, providing training,
for product and service design and collaborating, etc.
delivery Data Gathering Techniques
 Establish and use communication  Interviewing
channels (listening posts, feedback
mechanisms, etc.) with customers as a  Questionaires
resource for quality system  Observation
requirements  Repertory Grids
 Evaluate customer feedback for  Concept Mapping
continuous improvement opportunities
 Joint Application Design
Interviewing

10718221.doc
Page 1 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
 An interview is a systematic attempt to by the interviewee, and explain that
collect information from a person. brief notes will be taken and shared with
 Interviewing is the most widely used the interviewee after they have been
technique in requirements engineering. organized.
 Analysts interview future users of the  Often interviewees are concerned that
system individually to find out what the an analyst is trying to find fault with the
present system does and what changes way they work. One way to set them at
are needed ease is to get them to talk about
processes with which they are familiar.
 The information gathered during the
interviews enables the analysts to  The best interviews are those where the
design a new system that will eliminate interviewees do most of the talking.
the shortcomings of the current one. Therefore, analysts look for ways to get
Steps in Interview Process interviewees to open up to them.
 Preparing for the interview Closing the interview
 Planning and scheduling the interview  Closing the interview involves briefly
summarizing the areas that have been
 Opening and closing the interview
discussed, highlighting the important
 Conducting the interview facts and your understanding of them.
 Following up for clarification  This lets the interviewee know that you
Preparing for the interview have been listening carefully during the
 Before undertaking an interview, the interview and provides an opportunity
analyst should have a good for clarifying any misunderstandings.
understanding of the organization, its  During the summary, as well as during
industry setting, and the project's scope the entire interview, the analyst should
and objectives. adopt a posture of objectivity and avoid
 This involves reviewing : personal comments, observations, or
conclusions.
♦ organization reports, annual reports
 Finally, in closing, you must thank the
♦ long-range planning documents,
interviewee for the time and ask if a
♦ statements of departmental goals shorter follow-up interview can be
♦ existing procedure manuals and scheduled at a later date if necessary.
systems documentation
Conducting the Interview
♦ maybe even your old math or physics
text books  Active listening helps to maintain the
information flow and facilitates
 Analysts must understand common
adequate feedback from analyst to
industry terms and be somewhat
interviewee
familiar with the business problems of
the industry  The active listening technique has five
key tools
Planning and Scheduling the Interview
♦ Asking open-ended questions
 Prepare a list of topics and questions to
be covered to help ensure that ♦ Using appropriate words and phrases
important points are not overlooked and ♦ Giving acceptance cues
that the interview follows a logical
♦ Restating the interviewee's responses
progression.
 Scheduling interviews should proceed ♦ Using silence effectively
from the top down.  After the interview has been
 Heads of departments or sections are documented any clarification can
usually interviewed before employees usually be done by using closed
who report to them. questions.
 Interviewers should explain the purpose Structured & Unstructured Interviews
of the interview, the general areas to be  Unstructured Interviews - Advantages
covered, and the approximate amount
♦ Appropriate when the requirements
of time required to cover all areas
engineer wants to explore an issue
Opening and Closing an interview ♦ Facilitates description of domain in a
 In opening an interview introduce way that is easy for the interviewee
yourself, state the purpose of the ♦ Goal is to establish rapport and to get
interview, address any concerns raised a broad view
10718221.doc
Page 2 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
 Disadvantages ♦ Provides a good overview
♦ Data acquired is often unrelated and ♦ Able to convey non-linear structure
difficult to integrate better than other techniques.
♦ Often exhibits lack of structure Joint Application Design
♦Does not allow gathering of specific  Developed and taught by IBM
knowledge  It was developed to
♦ Takes time and training to do well
♦ shorten interviewing time (which
♦ Similar questions asked in future could take several weeks)
sessions may annoy interviewee
♦ overcome poor understanding of
Structured Interviews systems requirements
 Advantages ♦ increase users' understanding and
♦ Forces an organization on the commitment to the system
interview  Advantages
♦ Very goal-directed ♦ the analysis phase of the life cycle is
♦ Attempts to remove distortion from shortened
interviewees subjectively ♦ the specifications document
♦ Allows better integration of material produced are better accepted by the
after the interview users.
♦ Forces the interviewee to be Participants in JAD
systematic  Users - at all levels
♦ Requirements engineer identifies
 (one) IS analyst -- must listen to the
gaps in the knowledge which acts as
users
a basis for questions
♦ Purpose of session is clear to  observers -- provide technical
interviewee assistance and advice
 Disadvantages  scribes -- keep notes and circulate
them after meeting
♦ Needs more preparation by the
requirements engineer  session leader -- conducts the session
♦ Needs to study background material ♦ should not report to anyone in the
extensively group
Concept Mapping ♦ should aim for consensus, not
majority vote
 Concept maps may be formal or
 executive sponsor -- top executive
informal.
who emphasizes commitment
 Formal concept maps are usually
rigorous and used for specific, well ♦ is present at start and finish only
defined purposes Preparing for the workshop
 Informal concept maps are much more  locate an executive sponsor and
appropriate in interview situations determine scope
because they are easier to use (no  identify the participants
constraints), more flexible and  learn about the application
adaptable as the interview situation
changes  organize the meeting
 Concept mapping is useful as a note Conducting the session
taking technique and also useful to  The analysis covers the following points
share the map developed with the of a proposed system:
interviewee Planning
♦
Concept Mapping ♦ Receiving
 Shared concept mapping is useful ♦ Receipt processing/Tracking
because: ♦ Processing
♦ The map provides placeholders ♦ Recording
dangling discussion points ♦ Sending
♦ The structure helps to pinpoint ♦ Evaluating
obvious missing information Documenting the results
♦ The structrue helps to show
symetries in the information
10718221.doc
Page 3 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
 After the meeting, the scribes organize  The problems encountered must be
the materials and deliver them to the IS analyzed to see if they result from
analyst. The analyst prepares a failures, whether the failures are due to
specification document which may software bugs, and whether these bugs
include are caused by defects in the program
♦Management objectives  In development and maintenance
♦Scope and limits tracing the bugs to find the defects and
♦ Business questions the system will errors that caused them involves a long
answer and Information required to chain analysis starting with the
answer the questions operational behaviour of a complete
system
♦ Relationship with other systems
♦ Issues  In testing, problems are encountered
during operation and are analyzed to
♦ Menus, Screen and report layouts
determine their causes
♦ Processing rules and Operating
procedures  In inspections errors are directly
identified there by saving time and the
♦ Performance and operational
error measures obtained are more valid
requirements
than the data derived from operational
Problem Trend Analysis testing
 Errors These are basically human Classes of Defect Measures
mistakes E.g.,Typogrpahical errors,
syntactic errors.  Severity
 Symptoms
 Defects These are improper program
conditions that are generally the result  Where, When and How found
of an error E.g., Improper program  Where, When and How caused
packaging by non-programmers.  Where, When and How fixed
 Bugs A bug is a program defect that is Problem Discovery and Resolution
encountered in operation either under Data
test or in use. Bugs result from defects  Data required at problem discovery
but all defects do not cause bugs. time
 Failures A failure is a malfunction of a ♦ Who found the problem ?
user’s installation which may result from ♦ When the problem was found ?
a bug, incorrect installation, a
communication line hit, hardware ♦ What happened ?
failure, etc. ♦ What was being used ?
 Problems Problems are user- ♦ Is this a recurrence of a previously
encountered difficulties which may closed problem ?
result from failures, misuse, or ♦ What is the level of criticality ?
misunderstanding. Problems are human  Data required at problem resoultion
events where as failures are system time:
events
♦ Why did the program fail ?
Errors, Defects, Bugs, Faults &
Problems ♦ What was the solution ?
♦ Who supplied the resolution ?
Categ Items Causes
ory Measured ♦ When was it closed ?
Errors Human actions Programmer
mistakes Process Identification
Defects Program Errors  Definitions of Process
Properties
♦ a structured, measured set of
Bugs Program Program defects activities designed to produce a
malfunctions
specified output for a particular
Failures System Bugs & other customer or market
malfunctions malfunctions
♦ a collection of activities that takes
Problem Human Failures, human one or more kinds of input and
s perceptions errors human creates an output that is of value to
misconceptions
the customer
Process of Problem Analysis

10718221.doc
Page 4 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
♦ Any activity or group of activities that Points to be considered while
takes an input, adds value to it, and identifying a process
provides an output to an internal or  In a stream of activity, boundaries can
external customer be set anywhere one chooses.
♦ a systematic series of actions  The way to begin is to jump in; the
directed to the achievement of a goal place to begin is with results.
Typical processes in organizations  Many business processes take the form
PROCESS Converting products, and services of loops, cycles of events that are
1 coming in to products and services initiated, carried out, and, upon closure,
going out. reinitiated.
PROCESS Getting products and services from  Some business processes are
2 the producer to the customer or transformational; others are
the marketplace.
transactional.
PROCESS Influencing customers’ decisions to  Transformational business processes are
3 buy and to pay, that is, obtaining
concerned with converting
orders and payments.
organizational inputs into organizational
PROCESS Managing the money coming in, outputs.
4 the money going out, and any
surplus.  Transactional business processes are
concerned with exchanging outputs for
PROCESS Obtaining from suppliers the inputs
5 necessary to sustain the new inputs to continue the cycle of
functioning of the organization. events of which any given process is a
part.
Identifying Software Process
Post Implementation Review
 All software activities to be performed
on projects are decomposed into What is a PIR?
constituent elements to the granularity A Post Implementation Review (PIR) is a
needed to understand and describe the formal review of a programme or project of
activity. Each granule is identified as a IS-related business change. It is used to
process. answer the question: Did we achieve what
 E.g. product engineering is decomposed we set out to do, in business terms and if
into following process elements : not, what should be done
♦ software estimating element, Why is it important?
♦ software design element, A PIR is an essential component of the
♦ coding element, and benefits management process. It checks
whether benefits, including these set out in
♦ peer review element.
the business case have been achieved and
 Each of these elements are identified as identifies opportunities for further
a process improvement. Without a PIR, you cannot
Points to be considered while demonstrate that your investment in the
identifying a process programme of business change was
 Processes are selected portions of larger worthwhile.
streams of activity. Objectives of a PIR
 Business processes are portions of  demonstrate achievements against the
streams of activity that contribute to projected costs, benefits and timelines
business results. in the business case
 Results are the effects of actions taken.  identify opportunities to add additional
 Business results are always external to value to the system/project
the business, they are "out there.”  identify strengths and weaknesses of
 Business results are measured on the the project for future reference and
input side of an organization, not its appropriate action
output side.  make any other recommendations on
 An order or a payment received is a the future of the system/project.
business result; a product or service Who is involved ?
produced is not.
The SRO, as the owner of the business case
 To define is to establish boundaries.
for change, is ultimately responsible for the
 Boundaries must be set, not simply PIR. Team members conducting the review
discovered or identified. will typically include:

10718221.doc
Page 5 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
♦ people with working knowledge of change and where benefits were to
the business area under review and have been realised. As a minimum the
its processes PIR will usually assess:
♦ people with some technical ♦ the achievement (to date) of
knowledge appropriate to the business case objectives
information system aspects ♦ costs and benefits to date against
♦ strategy planners with knowledge of forecast, and other benefits realised
the organisation's IS strategy and the and expected
business change contribution to it ♦ continued alignment to the IS
♦ people involved in the everyday strategy
benefits management process. ♦ the effectiveness of revised business
Principles operations (functions, processes,
 Reviews help organisations to assess staff numbers etc.)
the contribution of IS/IT to business ♦ ways of maximising benefits and
objectives minimising cost and risk
 Project Evaluation Review (PER) and PIR ♦ the sensitivity of the business system
are related but have different objectives to expected business change
 PIRs are a key part of the benefits ♦ business and user satisfaction.
management process Identifying key sources of Information
 PIRs identify and appraise opportunities The views of stakeholders and customers
to improve the effectiveness of business form the basis for information gathered at
change by maximising benefits and by interviews and workshops. The main
minimising costs and risks sources of documented information will
 PIRs are not a one-off exercise include:
 Reviews must be conducted in an open ♦ the business case
manner; organisations must be ♦ information kept to track costs and
prepared to learn benefits
 Recommendations need to be ♦ the PER report or any previous PIR
implemented by the organisation if reports.
reviews are to add real value Information Gathering
The PIR Process Issues that need to be addressed will have
Process been identified in the scope of the PER and
Timing - The timing of the first PIR will PIR reviews. Business cases should include
depend on the predicted benefits stream provision for PERs and PIRs and for the
brought about by the business change, as collection of information that supports
predicted in the business case. Although them. The first task is to gather relevant
time must be allowed for benefits to accrue, information.
it is important that the PIR is completed Analysis
early enough to identify any problems. Analysis of the information gathered will
Remedial action can thus be taken promptly involve comparing what actually happened
if predicted benefits are not realised. The against that which was predicted (for
initial PIR should usually be carried out 6-18 example in a business case). It will examine
months after completion of the project. what was done well and what was done
Initiation and Responsibility badly; this forms the basis for
The owner of the business case for the recommendations. It is at this stage that
project will have overall responsibility for the data obtained from the information
tracking the contribution made to the gathering is brought together and coherent,
business, in terms of benefits realised. The useful and supportable recommendations
lead responsibility for the PIR will fall to the are formulated.
business area(s) where the day-to-day Reporting the Results
business change has been implemented The PIR is concerned mainly with
and where the responsibility for realising maximising the effectiveness of the
benefits lies. business change. PIRs are reported to
Identifying Scope and Stakeholders business managers in the area supported
 The scope of the PIR will be dictated by the information system and to the
largely by the business case, which will owners of the IS strategy business case.
have identified the areas of business Common Problems
10718221.doc
Page 6 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
 more than one organisation involved,  The purpose of Quality Planning is to
where there is no common standard for control the process performance of the
measuring and recording the benefits software project quantitatively and
and costs develop a quantitative understanding of
 lack of documentation. Much factual the quality of the project's software
information will come from project product and provide management with
documentation, especially the business appropriate visibility into the process
case being used by the software project and
of the products being built.
 lack or inadequacy of baseline
measures. For a PIR, measures of
success can only be made accurately by Activity and Logic Flow
comparing the level of performance Roles and Responsibilities
before the project implementation
against that at the time of the PIR  The Program Manager will ensure that
SQA review is complete before
 sensitivities. Examining the approving Quality Plans
performance of project teams, or
current operations against a predicted  Project Leader is responsible for (1)
level may lead to feelings of insecurity Preparing and releasing Quality Plan (2)
or grievance for those who were Organizing SQA Reviews
involved with the project, or in the  Measurement Assurance (MA) is
business area supported by the change responsible for Reviewing Quality plans
Common Problems to verify that it complies with QMS and
accepting the Quality plan by SQA sign-
 management of expectations. Although off
the use of reviews will improve the
effectiveness of the organisation, the  SQA is responsible for (1) Recommend
review team should ensure that they deviation / waiver request (2) Plan and
raise expectations of system conduct process review activities as per
enhancements or business change. quality plan
They may cost more to implement than  Management Representative has the
the value of the benefits they would authorization to Approve deviations /
deliver waivers to mandatory processes
 the organisation is too busy to do a PIR recommended by SQA
and never gets it done. There should be Activities in Quality Planning
policies to ensure that reviews are  Identify Quality Goals and Objectives for
carried out as part of the organisation's the project
normal practice
 Plan and report QPM & SQM activities
 lack of cooperation from the IS/IT
 Identify means to achieve Quality Goals
provider.
and Objectives
Quality Planning - Overview
 Prepare Project's Quality Plan
 Quality Planning process establishes the  Review by Customer
quality objectives of a project and
mechanisms to fulfill those objectives Identify Quality goals & Objectives

 It also specifies how Organization's QMS  Determine the quantitative quality goals
could be adapted to satisfy project suitable for the project
specific requirements  Quality Goals should be identified based
 The Quality Plan is compiled at the on Organization, Customer and end user
beginning of a project along with the requirements.
project plan to accomplish the quality  Product Quality goals in terms of the
goals Product characteristics such as
 The SQA group reviews project's quality Functionality, Reliability, Maintainability,
plan to ensure that organization Usability
standards, and procedures are  Quality goals may be tailored for the
established and that they are project based on Customer and/or End
appropriately tailored where ever User needs
required to meet customer  When there is a conflict between quality
requirements goals, the tradeoff decisions are taken
Quality Planning - Purpose
10718221.doc
Page 7 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
 Identify quality parameters to be project specific processes and the
measured product are defined
Plan and report QPM & SQM activities Preparation of Quality Plan
 Identify when the analysis would be  The plan should take care of scheduling
made to know the status of the Quality process reviews and internal audits as
Objectives based on the measures per the schedule announced by SQA.
collected  Describe how Organization's software
 Identify when the data analysis would process are tailored for the project
be made to check whether Quality  The components that will be reused in
objectives are met and also to identify the project are identified
corrective actions necessary
 The records to be maintained in the
 Analysis reports shall include the project as Quality Records are identified
Corrective and preventive actions that
were taken to bring the actual Review & Approve Project's Quality
performance in line with performance Plan
limits set for the project  The software quality assurance group
 The results of analysis are reported to reviews project's quality plan to ensure
Program manager /project manager, the that organization standards, and
report can be incorporated in Project procedures are established and that
Status reports they are appropriately tailored where
ever required to meet customer
Identify means to achieve Quality requirements.
Goals and Objectives
 The Quality Plan is approved by
 Project's SQA activities by team Program Manager and placed under
members Document Control
♦ Identify verification and validation  If it had been agreed with customer that
activities, which are needed their SQA will be involved, Quality Plan
♦ Determine process adherence and is sent to customer SQA for review and
identify standards. Identify the approval
processes that will address the Review by Customer
chosen phases and deliverables. E.g.
reviews would be carried out using  If it has been agreed with customer,
Reviews process. customer's SQA personnel may review
SQA activities for the project as per the
Project's SQA Activities by SQA project's quality plan. The reviews may
member be in the form of tele-conference or by
 Participate in Project Planning providing or seeking clarifications over
 Conduct Reviews of Plans and Work email on a need basis. Tele-conference
products reviews are minuted.
 Conduct Process Reviews Verification
 Conduct inspection for product  Project Leader initiates reviews on
certification project artifacts and product
certification and SQA ensures that the
 Handling deviations reviews are conducted as per the plan.
 Project Windup  Program Manager ensures that Process
Prepare Project's Quality Plan Reviews are conducted as per the plan
 Project’s Quality objectives are defined and all corrective actions are planned
for each life cycle phase of the project and tracked to closure

 Tailoring may be performed to arrive at  Internal and external audits and

the set of Quality Objectives for the assessments are held to review the
project activities and software work products of
the project's SQA group
 Quality control activities to be
performed and responsibilities for Statistical Quality Control Tools
performing the activities are defined  Pareto Chart - Pareto diagrams are
 QPM & SQM activities to be performed simple bar graphs that focus attention
including identification of measures for on the factors that are most significant
to a problem.They can be used to

10718221.doc
Page 8 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
♦ Display which path or problems to group focused on) in a box at the right-
pursue first. hand side of your diagram.
♦ Indicate where to concentrate our  STEP 2 - Identify the categories in which
limited resources to make the you expect to find the cause(s) of the
biggest improvement. problem. Label the major bones of the
♦ Focus attention on the critical (“vital fish with these categories. Common
few”) problems in a rational, ones:
systematic way ♦ Machines, Methods, Materials,
♦ Track progress and document people, Information, Environment,
improvement by comparing changes Measurements.
from one time period to another. ♦ Major bones might also be major
♦ Investigate possible causes from a steps in the process. This
cause-and-effect diagram. arrangement helps identify where
process problems emerge.
Tips for using Pareto Charts
 STEP 3 - Review the ground rules for
 Look for a bend or elbow in the brainstorming. Brainstorm a list of all
cumulative-effects line. This separates possible causes. Remind the team that
the “ vital few” from the “ trivial many.” you are looking for causes, not
If no clear elbow exists, try re- solutions.
categorizing or stratifying the data.
 STEP 4 - Identify what data to collect
 Other than frequency of occurrence, the focus on “ root causes.”
categories can be ordered by other
criteria such as cost, waste, tons,  STEP 5 - Collect and evaluate the data
hours,etc to systematically eliminate potential
causes.
 The left-hand vertical axis should
represent a loss (i.e.,. hours down, cost, ♦ This step is sometimes difficult and
frequency of errors). may take a lot of time. However, it is
very important if your team is going
 The left-hand vertical axis should go to develop solutions that will get at
from zero to the total number of data the real root causes and solve the
points (or total cost, etc.). The right- problem.
hand vertical axis should go from zero
to 100 percent.  STEP 6 - Test to verify the most likely
cause by collecting new data to confirm
 Avoid mixing causes of the problem and your prediction.
situations under which they occur on
the same Pareto. Tips for Using Cause and Effect
Diagrams
Cause and Effect diagrams
 Keep Keep asking Why? Why? Why?
 Cause and effect diagrams are tools for Why? Why?
gathering and organizing ideas on what
causes might lead to a particular effect.  Ask, “ What has changed?” in
They are also called fishbone diagrams. identifying the most likely causes of a
These diagrams can be used to: new problem. Deviations from the norm
are good clues to the possible “ root
♦ Identify potential causes of a cause” of a new problem.
particular effect.
 Make sure all your “ causes” are, in fact,
♦ Prevent “tunnel” vision by expanding potential causes rather than solutions.
beyond obvious potential causes. Often, causes that the begin with “ lack
♦ Communicate the relationship of of “ are hidden solutions.
potential causes to the problem.  Don’t over look the category of
♦ Help determine what data to collect, measurement – find out if you really do
to focus in on, and verify the “root have a problem or whether just the
cause(s)” measurement of it has changed.
♦ Improve a team’s focus on the most  Use other Q1 tools, e.g.,. Scatter
probable causes. diagram or Pareto, to help determine if
How to Prepare Cause and Effect potential causes did, indeed, cause the
Diagrams problem.

 STEP 1 - Write the effect ( the problem  Remember that it is often possible that
statement, or a more specific effect the several “root cause” exist.

10718221.doc
Page 9 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
Flow Charts STEP Write down the problem or issue
 Flow charts are diagrams that show the 2 for idea generation
actual sequence of steps in a process. STEP Each person randomly calls out
 They are used to: 3 ideas
♦ Help a team understand a process. STEP Each idea is written on chart
♦ Educate team on process steps. 4 paper as it is called out. Ideas
should be visible at all times.
♦ Find unnecessary or missing steps in
the current process. STEP If any idea is discussed or
5 criticized, the leader reminds the
♦ Highlight areas in which to look in group of the rules.
more detail.
STEP When the group has “ run dry” the
How to Prepare Flow Diagrams 6 leader may use “ prompts” such
STEP Gather the people with the greatest as, “ what if money was not an
1 amount of knowledge about the issue?” to generate more ideas.
process.
STEP If necessary, the group may ask
STEP Clearly define the area of the process 7 for clarification of earlier ideas.
2 under consideration, specify the
beginning and ending points. Structured Brainstorming
STEP Decide what level of detail is  STEPS 1 & 2 same as above
3 appropriate. It’s a good idea to start
 STEP 3 - Each person silently writes
with a less detailed flow diagram,
then look at specific portions in more down as many ideas as possible.
depth, if necessary.  STEP 4 - In sequence, each shares one
STEP Diagram the steps that are currently idea is written on chart paper. Ideas
4 followed, not what should happen should always be visible.
STEP Consider other steps that might  STEP 5 - If any idea is discussed or
5 improve the results or streamline the criticised, the leader reminds the group
process without affecting quality. of the rules.
STEP Construct a new diagram of the  STEP 6 - When all ideas are exhausted,
6 revised process, if necessary. each person should say “ pass,” until all
Tips for Using Flow Diagrams pass. The leader may then use “
prompts” if necessary.
 Start by clearly specifying the beginning
and ending points of the process  STEP 7 - If necessary, the group may
ask for clarification of earlier ideas.
 Label flow lines, especially those for a
continuous process, by indicating what Tips for Brainstorming Sessions
is flowing from step to step: e.g., ships,  Clearly define the objective of each
pulp, corrugated medium, gas, etc. session.
 Try using Post-It notes or “ sticky pads”  Encourage everyone to participate.
at the beginning stages of building a
flow diagram. It’s easier to make  Write down exactly what people say.
change later.  After your brainstormed list is
Brainstorming generated, review and combine like
ideas.
 Brainstorming is a method of tapping
the mental resources of an entire group.  Reduce your list to a manageable
It can be used to : number using voting and ranking
techniques, then try to gain consensus.
♦Identify problems for a team to work
on.  Guidelines for the group:
♦ Identify what data to collect at any Do not criticize or evaluate ideas.
♦

step. ♦ Go for quantity rather than quality.

♦ Identify possible “ causes” for a ♦ “ Wild” ideas are fine.
cause- and – effect diagram. ♦ Build on previous ideas.
♦ Generate potential solutions. Histograms
How to perform Brainstorming  Histograms display how a particular
STEP Review the guidelines (see Tips characteristic varies when it is
1 for Brainstorming Sessions) with measured many times. They can be
the group. used to:

10718221.doc
Page 10 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
♦ Show the “center” of the measured ♦ Note: You may want to use
values, i.e.,. where most of the values percentages of the total rather than
tend to fall. count on the vertical axis.
♦ Show the spread or variation in the ♦ Draw the bars.
measured values.  STEP 8 - Label both the horizontal and
♦ Show the shape or distribution of the vertical axes, and give a descriptive title
values about the center. to the histogram.
♦ Compare one lot or group with Tips for Using Histograms
others.  Try to have at least 30 data points -
♦ Compare actual distribution to fewer than this will not be enough to
desired specifications. give you a representative picture.
How to Prepare Histograms  Get good samples, ones that are fair
 STEP 1 Collect data for one and representative.
characteristic in a check sheet.  Make sure every bar in the histogram is
 STEP 2 Subtract the smallest value in the same width. Height will vary, but
the check sheet from the largest to find width must be identical.
the “ range”  Make sure you are looking at only one
 STEP 3 Decide on how many columns numeric characteristic in each
(bars) the histogram should have, The histogram(variables data)
following guidelines can help: If you are going to compare two or more
No of Data Points histograms, make sure they have the same
Approximate No of Columns column boundaries and vertical scales.
30-49 5 Scatter Diagrams
50-100 6-10  Scatter diagrams are that display how
one’s characteristics (variable) relates
101-250 7-12 to another. They can be used to:
More than 250 10-20 Determine if a relationship exists
♦
between two characteristics.
 STEP 4 Determine the column width as ♦ Determine the strength of a
follows: Range relationship.
Column = ------------------ ♦ Visually display the relationship.
# of Columns
♦ Investigate possible causes from a
You may want to round off to a number cause and effect diagram to see if
that is easy to work with. they are related to the effect.
 STEP 5 Determine the Column ♦ Determine whether a relationship is
boundaries: positive( as one variable increases,
♦ Pick a starting number smaller than the other increases), or negative ( as
or equal to the smallest value on the one variable increase, the other
check sheet. decreases).
♦ Add the column width to the starting How to Prepare Scatter Diagrams
number to get the next boundary.  The scatter diagram gets its name
♦ Add the column width again to get because it shows a relationship by
the next boundary. plotting (“scattering”) dots on a graph.
♦ Repeat until you have expected the Each dot represents one occurrence or
largest value from the check sheet. observation.
 STEP 6 - Count how values from the STEP Brainstorm what characteristics
check sheet fall into each column. 1 (variables) might be related.

 STEP 7 - Make a histogram. STEP Prepare a check sheet and collect the
2 date. Remember that the data should
♦ On the horizontal axis, write number represent all solutions. Try to collect
showing the boundaries. at least 30 values.
♦ For the vertical axis, find the largest STEP For each scatter diagram, select two
column count and make the vertical 3 characteristics you want to test.
axis go at least that high. STEP Find the largest and smallest values
4 for each of the two characteristics

10718221.doc
Page 11 of 12
Syntel CQA Forum Quality Principles in Nutshell Part II CQA Doc No 2
that you will be plotting. How to Prepare Control Charts
STEP Make the length of both axes STEP Determine which process
5 approximately the same and place the 1 characteristics need to be controlled
numeral values along each axis. to best meet customer requirements
STEP Label each axis and title the diagram STEP Decide which type of control chart is
6 with a brief description of what it 2 most appropriate for the process
represents. characteristics.
STEP Plot the point for each pair of STEP Choose a period of time when the
7 observations. 3 process under study is relatively
stable & collect at least 25 data
points.
Tips for Using Scatter Diagrams STEP Use appropriate formulae to calculate
 Make sure data provides a true picture 4 the center line and upper and lower
by collecting some from all shifts, control limits.
customers, conditions,(e.g., moisture, STEP Plot the data as a run chart and add
season)etc. 5 the centerline and control limits.
 Stratify data by using different marks of STEP Use the control chart regularly,
colors on a scatter diagram. 6 thoroughly investigating any out-of-
Stratification helps isolate relationships control conditions.
that may appear within a grade, shift, Tips for Using Control Charts
size, etc.  Do not confuse control limits with
 Determine the strength of a relationship specifications. Control limits indicate
by calculating the “correlation what the process is capable of
coefficient”. The correlation coefficient producing; specifications indicate what
can arrange from – 1.0(maximum the customer expects.
negative relationship) to +  Do not add specifications to your control
1.0(maximum positive relationship). A chart.
correlation coefficient near zero
indicates no relationship.  The following patterns indicate out-of-
control (non-consistent) behavior:
 Put causes on the horizontal axis and
effects on the vertical axis. ♦ One point outside the control limits.
 Plan for stratification of data. You may ♦ Seven consecutive points on the
need several run charts (one for data same side of the center line.
combined others for data broken down ♦ Seven consecutive using ( or falling)
through stratification). points
Control Charts ♦ Repeated cycles.
 Control Charts are line graphs of a ♦ Points hugging the center line ( or
characteristic showing changes over control limits).
time and their impact on the state of
control of a process. They can be used
to:
♦ Visually display a history of the
process.
♦ Point to problems and help to identify
their root causes.
♦ Serve as an early warning signal.
♦ Keep people from “ fiddling” with a
stable spot.
♦ Help people determine the inherent
capability of a process.
♦ Show when a process shifts from one
level to another or drifts out of
control.
♦ Assist in understanding process
variability.
♦ Monitor and predict the output
quality of process.
10718221.doc
Page 12 of 12