Quality plan

• A quality plan is a document, or several

documents, that together
specify quality standards, practices, resources,
specifications, and the sequence of activities
relevant to a particular product, service,
project, or contract.
 Quality plans should define:
• Objectives to be attained (for example, characteristics or
specifications, uniformity, effectiveness, aesthetics, cycle time,
cost, natural resources, utilization, yield, dependability, and so on)
• Steps in the processes that constitute the operating practice or
procedures of the organization
• Allocation of responsibilities, authority, and resources during the
different phases of the process or project
• Specific documented standards, practices, procedures, and
instructions to be applied
• Suitable testing, inspection, examination, and audit programs at
appropriate stages
• A documented procedure for changes and modifications to a
quality plan as a process is improved
• A method for measuring the achievement of the quality objectives
• Other actions necessary to meet the objectives
 QUALITY PLAN EXAMPLE
• An example of a quality plan is a manufacturing company that machines
metal parts. Its quality plan consists of applicable procedures (describing
the production process and responsibilities), applicable workmanship
standards, the measurement tolerances acceptable, the description of the
material standards, and so forth. These may all be separate documents.
• More variable information that pertains to a particular customer may be
spelled out on individual work orders (sometimes called travelers). Work
orders specify the machine setups and tolerances, operations to be
performed, tests, inspections, handling, storing, packaging, and delivery
steps to be followed.
• An operating-level quality plan translates the customer requirements (the
what) into actions required to produce the desired outcome (the how) and
couples this with applicable procedures, standards, practices, and protocols
to specify precisely what is needed, who will do it, and how it will be done.
A quality control plan may specify product tolerances, testing parameters,
and acceptance criteria. While the terminology may differ, the basic
approach is similar for service and other types of organizations.
 QA plan
• A quality assurance plan is a document,
constructed by the project team, meant to
ensure the final products are of the utmost
quality. A quality assurance plancontains a set
of documented activities meant to ensure that
customers are satisfied with the goods or
services a company provides.
• Purpose
• Reference
• Management
• Documentation
• Standard practices and conventions
• Reviews and audits
• Configuration management
• Problem reporting and methodologies
• Code control
• Media control
• Supplier control
 Quality Assurance Functions:
There are 5 primary Quality Assurance Functions:
• Technology transfer: This function involves getting a
product design document as well as trial and error data and
its evaluation. The documents are distributed, checked and
approved
• Validation: Here validation master plan for the entire
system is prepared. Approval of test criteria for validating
product and process is set. Resource planning for execution
of a validation plan is done.
• Documentation: This function controls the distribution and
archiving of documents. Any change in a document is made
by adopting the proper change control procedure. Approval
of all types of documents.
• Assuring Quality of products
• Quality improvement plans
 Project checkpoints
• ILLUSTRATING THE CHECKPOINT MANAGEMENT PROCESS
• To illustrate checkpoint utilization, we can use a project
structure organized into five (5) phases, as follows:
• Phase 1: Requirements. To define technical and business
requirements for the project.
• Phase 2: Design. To design the technical deliverables.
• Phase 3: Development. To develop and test the technical
solution.
• Phase 4: Implementation. To deploy and support the roll-
out of the technical deliverables.
• Phase 5: Closure. To transition the project and deliverables
from project status to operational status.
 Continuing with this illustration, the following checkpoint "decision tree"
leads the way through the progression process.
Setting Checkpoints for "Phase 1: Requirements"
• Have all "requirements" tasks been completed?
• Are there any open issues?
• How will these issues be resolved?
• Are the established requirements sufficient to proceed to the next phase?
• If not, requirements related problems must be resolved, mitigated or
waived before progress can be made.
Setting Checkpoints for "Phase 2: Design"
• Have all "design" tasks been completed?
• Does the design meet the established requirements?
• Are there any open design issues?
• How will these issues be resolved?
• Does the design function as expected?
• Is the design ready to proceed to the next phase? If not, design
related problems must be resolved, mitigated or waived before
progress can be made.
Setting Checkpoints for "Phase 3: Development"
• Have all "development and testing" tasks been completed?
• Does the system perform as expected?
• Are there any open development issues?
• How will these issues be resolved?
• Is the system ready to proceed to the next phase?
• If not, development related problems must be resolved, mitigated
or waived before progress can be made.
Setting Checkpoints for "Phase 4: Implementation"
• Have all "implementation" tasks been completed?
• Are there any open issues?
• How will these issues be resolved?
• Is the project ready to proceed to the next phase? If not,
implementation related problems must be resolved, mitigated or
waived before progress can be made.
Setting Checkpoints for "Phase 5: Closure"
• Have all "closure and transition" tasks been completed?
• Are there any open issues?
• How will these issues be resolved?
• Have all necessary "closure and acceptance" approvals been
obtained.
• Has the lessons learned review been completed?
• Can the project be closed? If not, closure related issues must be
resolved mitigated or waived before the project can be closed.
 PROJECT CLOSURE
• The Project Closure Phase is the fourth and
last phase in the project life cycle. Between
one and three months after the project has
been closed and the business has begun to
experience the benefits provided by the
project, you need to complete a Post
Implementation Review.
• The Project Closure Report is the
final document produced for the project and
is used by senior management to assess the
success of the project, identify best practices
for future projects, resolve all open issues, and
formally close the project.