Project Quality Management Plan

Quality Management Plan
<Project Name>
Template provided by Cortelligence Consulting
The following template is provided for use with Project Quality Management Plan deliverable. The blue
text provides guidance to the author, and it should be deleted before publishing the document.
This document should be modified to the Author’s project requirements.

<Your Company Name> Quality Management Plan
<Project Name>
Quality Management Plan Template provided by Cortelligence Consulting (www.cortelligence.com)Page 3
14.2 Software Versions.......................................................................................................................27
15 Peer Review Form...........................................................................................................................28
16 Approvals ........................................................................................................................................29
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/project-quality-management-plan-2954

<Project Name>
2 Related Documents
Document Version

<Project Name>
4 Roles and Responsibilities
Project management sets the scope and direction of Quality Review Planning. Project Management is
responsible for ensuring that Quality Reviews are conducted in a continuous process throughout the
project life cycle. Major roles include:
• Provide Overall Direction: Delivery Leads and Project Manager
• Plan Development and Execution: Team Leads/Team Members
• Participate in Quality Reviews: Project Manager/Team Leads/Team Members
• Assist team leads in collecting and analyzing Peer Review Data: Project Manager
4.1 Project Roles and Responsibilities Overview
Overview of responsibilities:
• Develop and maintain Quality Review Process.
• Develop and maintain deliverables/work products undergoing Quality Reviews.
• Identify deliverables/work products applicable to Quality Reviews.
• Ensure compliance of processes and deliverables/work products to project standards and
procedures.
• Discuss upcoming Quality Reviews during project meetings.
• Identify and remove defects in deliverables/work products early and efficiently.
• Verify the progression of client engagements.
• Document and report issues and defects.
• Participate in Quality Reviews.
• Track Change Requests (CRs) and reduce them as the work effort progresses.
• Verify that the specification package meets all requirements (e.g., business needs, explicit and
implicit user requirements, etc.).
• Verify that project requirements were correctly transformed into code.

<Project Name>
The diagram below illustrates the V-Model approach.
Business Requirements
Functional Requirements
High Level Design
Detailed Design
Software Build
Unit Tests
Integration Tests
System Tests
Acceptance Tests
System Test Cases
Integration Test Cases
Unit Test
Cases
V MODEL
A development effort begins on the left-hand side of the V-Model, with requirements gathering and
design activities. We specify the project top down, making decisions and adding more detail at each new
specification stage. When the design is complete, the software build processes begin. Once construction
is complete, the product moves through the testing activities on the right hand side of the V-Model.
During the earlier stages of testing, the focus is on individual components. As testing progresses, the
focus is on functionality and the achievement of the stated requirements. Meanwhile, verification and
validation actions are taking place all throughout the V-model project life cycle.
The V-Model diagram shows the workflow in the development process with requirements analysis and
design activities on the left side and corresponding testing activities on the right side. During each
analysis or design stage, a test plan is developed, which documents the test conditions and expected
results required to test the implementation of the specification in the corresponding testing activity.
This plan drives the testing activity, defining the level of detail and specific objectives of the activity. In
addition, the early development of the test plan, during the analysis or design stage, ensures that the
specifications being developed are testable, and that complete and comprehensive test conditions are
defined by the people who best understand the specifications. The testing done on the right side of the
V-Model tests that the related specification developed on the left side is properly implemented.
This approach provides for the following benefits:
• Improved quality and reliability
• Reduction in the amount of rework
• Reduction in the cost of problem correction
• Efficient testing by focusing on the objectives of the various tests

<Project Name>
originating in detail design before they transition into
assembly or product test phases.
Assembly Test Tests that two system parts interconnect and interact
according to the solution design. Also tests the dialogue
flow between screens is correct for screen based
applications.
Product Test Test that the systems functional behavior is correct in its
entirety. This is checked against the systems behavior,
described by the Business use cases and the Business
requirements document.
IAT (Integration Acceptance
Test)
A shake down test inside the GST type of environment
Performance Test Performance test is aimed at establishing the system’s peak
through-put, endurance and peak number of concurrent
user sessions. The Performance Test tries to establish if the
SLA on user wait time and system wide availability are
going to be met.
GST (Global System Test) A cut down version of the Product Test proving that the
functionality is preserved in a production like environment
OAT Operation Acceptance Test. The operations / run
community test that they have everything they need to run
the system when it comes live. Test to see if the system is
ready to be accepted by this community.
UAT User Acceptance Test. (Apart of Validation Section)

<Project Name>
9 Validation
Validation is performed to ensure that the system/product being developed can be used as it was
intended in its operating environment. In other words, validation makes sure the right thing was built.
Specifications should be validated to ensure that the development process is still on track to provide a
solution that meets the requirements and the Business Case.
9.1 Validation Approach
The project accomplishes validation through a staggered set of Development Deliverables and User
Acceptance Testing (UAT). The reviewer is able to review all development documentation to ensure the
system is being built for its intended use. In addition, the client will get the chance to execute UAT upon
completion of the development phase. This type of validation allows the project team and the client to
ensure the developed system was built correctly.
In order to facilitate validation, Development Deliverables documentation will be given to the client
throughout the development phase. This will ensure the client that the project team is building a system
for which it was intended.
Another one of the testing requirements is the User Acceptance Testing. The UAT is prepared during the
development phase, and as soon as development is complete, the UAT will begin.
9.2 Validation Items and Acceptance Criteria
In order for the Development Deliverables to be accepted, the Client Officer delegates must first review
these and provide comments. Once these have been accepted, the comments are reflected in the
document sign off on each of the deliverable packets. There is a set of pre-agreed criteria for each
deliverable. With this signoff, the client is agreeing that their product is being developed in a manner in
which they see fit. Formal reviews are expected within 5 working days. Realistically it is worth planning a
5/3/2 approach that works in the following manner:
• The document is sent out for formal review with the review sheet. The client has UP TO 5 days to supply
comments in the template supplied. Gently remind the reviewers after 3 days if nothing is received.
• The author has then UP TO 3 days to incorporate the comments or to resolve points raised with the reviewer.
3 days is the maximum not the intended.
• The reviewer has then up to 2 days to accept the changes / comments. No response is deemed as acceptation.
In order for the UAT to be accepted, the client must sign off on the testing as a whole. Another
acceptance criterion is to ensure that the test documents and scripts cover the requirements outlined in
the requirements document.

<Project Name>
10 Quality Review Process
The Product and Process (Software) Quality Assurance (PPQA/SQA) process verifies that management
practices and deliverables/work products comply with project standards and procedures. PPQA/SQA
reviews and supports the delivery of high-quality products and services.
An SQA review is a methodical examination of work products, project management processes, high-level
development processes, and day-to-day practices by an objective reviewer to ensure compliance to the
project’s documented processes and standards.
SQA review benefits include the following:
• Provide timely verification of the project's products and the related software development process.
• Identify issues and concerns early, resulting in cost and time savings (i.e. reduced re-work).
• Identify opportunities for continuous improvement on existing processes.
• Provide coaching on best practices and templates to the project teams.
This process is represented in the following diagram:

<Project Name>
Project
Phase
Deliverable/
Work Product
Type of
Review
Timing of
Review
Documentation
Required
Reviewer(s) Review
Technique
Design High Fidelity
Prototype
Product
Quality
Assurance -
Peer Review
When draft
is complete
– at least 5
days prior
to due date
Peer Review Form Designer
Usability Expert
Functional
Architect
Unfacilitated
Peer Review
Design Component
Design
Document
Product
Quality
Assurance -
Peer Review
When draft
is complete
– at least 5
days prior
to due date
Peer Review
Feedback Form
Peer Review
Criteria
Team Lead Unfacilitated
Peer Review
Build Medium and
Complex
Development
Modules
Product
Quality
Assurance -
Peer Review
After Unit
Test – at
least 5 days
prior to due
date
Peer Review
Feedback Form
Peer Review
Criteria
Developers,
Development
Team Leads,
and Designer
Facilitated
Peer Review
Build Low
Complexity
modules
Product
Quality
Assurance -
Peer Review
After Unit
Test – at
least 3 days
prior to due
date
Peer Review
Feedback Form
Peer Review
Criteria
Developers,
Development
Team Leads
and Designer
Facilitated
Peer Review
Unit Test Medium and
Complex
Development
modules
Product
Quality
Assurance -
Peer Review
After Unit
Test – at
least 3 days
prior to due
date
Junit Test case
demonstrating
that all 3 classes
of test conditions
have been met :
1) Normal
processing
conditions
2) Boundary
processing
conditions
3) Error
processing
conditions
Senior
Developer /
Team Lead
Facilitated
Peer Review

<Project Name>
11.2.1 Plan for Review
• Identify the work products that need to be peer reviewed
• Schedule the Peer Review on a work product before it migrates to the next phase of development and at least
one week before the work product’s due date
• Document standard Peer Review criteria
• Identify eligible peer reviewers
• Select the most appropriate technique for the Peer Review (Facilitated or Un-facilitated)
• Retrieve the correct Peer review form – See section 15 for location of form
11.2.2 Prepare for Peer Review
After planning for Peer Reviews, the project needs to prepare for the Peer Review.
The Deliverable Owner responsibilities include:
• Send the deliverable/work product, Peer Review Feedback Form, and Peer Review Criteria at least one day
before the review to Peer Reviewers. If the deliverable is code package – then sending a link to the correct
place in clear case is more appropriate.
The Peer Reviewer is responsible for:
• Setting aside the time to conduct the review and familiarize himself or herself with the subject.
• Reading the deliverable/work product prior to the review meeting for a facilitated review
• Documenting comments for the deliverable/work product
11.2.3 Conduct Peer Review
After preparing for the Peer Review, the project needs to conduct the Peer Review using the technique
identified during planning. The purpose of this step is to drive errors out early in the lifecycle and to
make sure that work products adhere to project standards. Peer reviewers note recommended changes
to the deliverable/work product in the peer review. The review will be conducted at least three days
prior to due date.
For Development efforts, all complex work products will be peer reviewed and documented while only
50% of medium level complexity work products will be documented and 20% of the low complexity
work products’ peer reviews will be documented.
Roles and Responsibilities for the Facilitated Peer Review technique are as follows:
The Deliverable/Work Product Owner responsibilities include:
• Participate in the Peer Review discussion
• Clarify deliverable questions
• Document time spent on the Peer Review
• Provide feedback on the Peer Review process regarding improvements, and changes to the Team Lead or
Project Manager
Appoint a facilitator and a meeting recorder

<Project Name>
The Peer Reviewer(s) responsibilities include:
• Provide recommendations, comments, and changes to the deliverable/work product using the Peer Review
Criteria
• Provide constructive criticism on the deliverable/work product being reviewed
• Contact Peer Reviewee to discuss disagreements (if necessary). If a resolution cannot be reached with the
Peer Reviewee, escalate issue to the Project Manager
• Provide feedback on the Peer Review process regarding improvements and changes to the Team Lead or
Project Manager
*Note that only Peer Reviewer(s) that are qualified and understand the material to be reviewed should
conduct an Un-facilitated Peer Review.
**Note that multiple Peer Reviews may be conducted for the same work product. If several reviews are
scheduled, use a single Peer Review Feedback Form to capture data for all peer reviews of the work
product.
11.2.4 Peer Review Criteria
Peer Reviews will occur at the following phases: Analysis, Design, Build and Product Test Preparation.
The Criteria for the peer review are the set of checklists tailored for each phase. The tailoring of the
checklist from the standard template should be completed when entering each of the phases.
11.2.5 Perform Necessary Rework
The next step is performing necessary rework.
The Deliverable/Work Product Owner responsibilities include:
• Perform necessary rework as suggested in the Peer Review Feedback Form
• Record resolution in the Peer Review Feedback Form
• Document time spent correcting problems (defects and errors)
• Monitor the status of problems (defects and errors)
• Forward Peer Review metrics to Team Lead or Metrics Lead on the project
The Team Lead responsibilities include:
• Review changes with the Deliverable/Work Product Owner (Team Lead only)
11.2.6 Analyze Review Results
The final step of the Peer Review process is to analyze review results. The Team Lead submits Peer
Review metrics to Project Manager or Metrics Lead for analysis. Peer Review data is analyzed as
indicated in the Project Measurement Plan.
The Team Lead responsibilities include:
• Review individual Peer Review Feedback Forms for possible recording errors.

<Project Name>
Conduct Management Plan Reviews (one-time activity per plan)
Brief Description Review of all completed mandatory project management plans to ensure they
meet all planed requirements.
Expected
Outcomes/ Outputs
• After completion of the PPQA management plan reviews:
• Any non-conformance items that were identified during the review are
documented in the PPQA Report and discussed with the plan owner
• All non-conformance items are closed by the plan owner and tracked to
completion in the PPQA Report to meet the preferred practice criteria
and have a final, approved plan
People Involved • The Reviewer completes the PPQA review for all required plans, discusses
non-conformance items and verifies the successful completion of the non-
conformance items.
• The project team member who owns the plan understands the non-
conformance items and successfully completes them.
Inputs / Available
Tools
• Management Plans Review Checklists
• Project’s Consolidated Project Plan
• Project’s Configuration Management Plan
• Project’s Quality Management Plan
• Project’s Risk Management Plan
• Project’s Measurement Plan
The QPI Teams will forward the findings to the Project Manager and Engagement Partner prior to
making the report available.
11.4 Process QA – Management Practices Reviews (Best practices reviews)
Management Practices Reviews (QPI refer to these reviews as Best Practices reviews) are a methodical
examination of management processes, high-level development processes, and day-to-day practices by
an objective reviewer to ensure compliance to the project’s documented processes and standards.
These reviews are conducted from a functional perspective.
Best Practice reviews check existing processes against the list of best practices. This process ensures that
projects are implementing the Delivery Methodology effectively and provide an opportunity to coach
teams on implementing Best Practices. These reviews are conducted by the QPI team. The QPI team is
committed to providing support and guidance on standards, methodologies, templates and tools. This
review process ensures that projects deliver high quality client service by developing, maintaining and
deploying best practices, methodologies, tools and knowledge capital using the Capability Maturity
Model Integrated (CMMI) framework. In addition to verifying ADM adoption and CMM compliance Best
Practice Reviews themselves are a required component of Software Quality Assurance KPA (SQA - CMM
SW Level 2 requirement) as well as Process and Product Quality Assurance PA (PPQA - CMMI Level 2
requirement).

<Project Name>
11.5 Quality Assessment (QA) Review
The Quality Assessment (QA) Review is a formal review of a client engagement by a Partner who is external to the
engagement. The primary purpose of the review is to verify that each client engagement is progressing based on
client expectations, will bring business value to the client and deliver the solution on time and within budget. The
QA Partner is responsible for conducting reviews. The reviews are conducted quarterly at the beginning of the
project and then semi-annually as the project progresses.
12 Milestones
In order to achieve the quality goals outlined in this plan, there are a number of milestones that the
project must achieve. The following are the quality milestones for the project:
• Approach Best Practice Reviews – held on a monthly basis, to determine that the project is applying the
methodology consistently.
• Agree on Templates and standards for work products
• Peer Review Checklists for the Analysis phase customized
• Analyze Deliverables Peer Reviews Completed
• Peer Review Checklists for Design phase customized
• Design Deliverables Peer Reviews Completed
• Peer Review Checklists for the Build phase customized
• Build Deliverables Peer Reviews Completed
• Tailor Peer Review Checklists for Test phase
• Test Deliverables Peer Reviews Completed
• Successful Unit Test
• Successful System Test
• Successful User Acceptance Test
Dates may vary until the plan has been baselined
13 Measures
Project teams will use the Project Metrics Plan to measure the effectiveness and success of the
processes documented in this plan. The Metrics Plan outlines the metrics that will assist management in
making informed decisions to promote quality, productivity, and process improvement. The plan
ensures that the metrics defined are aligned to business and program objectives, and that the metrics
are implemented in an organized and planned approach.
The primary quality metrics that will be used are:
• Peer Review Problem Detection – total number of problems found versus work unit size
• Peer Review Effectiveness Ratio – number of problems found per hour spent

<Project Name>
14 Project Specific Standards
Architectural standards:
The project will make 'best endeavors' to adhere to the following client’s specific standards:
XYZ Architecture
EGS Construction Guide
EBS Cookbook
Java Standards
Style Guide
In addition is it expected that EBS Framework helper classes will be created to meet the existing
standards and will co-exist with the existing application. Any additional classes will be designed for re-
use across the EBS layer within future releases.
Minor discrepancies can be anticipated where these standard are not fully consistent or verifiable.
Whilst the project is keen to support the ongoing enhancement of both standards and the common
component catalogue, this must be weighed up against any extra work effort and risk to delivery.
Changes to these standards are welcome, especially where there is an identifiable business
requirement. These changes will be subject to a change control process to assess the likely impact on
the project before being adopted as standards.
14.1 Common components
The project will endeavor to use the most recent, demonstrably stable set of common components
available – i.e. components that have already been deployed and tested in a live environment.
Therefore, where appropriate, the project will make use of the following common components.
• EGS components
Whilst the project is keen to support the ongoing enhancement of both standards and the common
component catalogue, this must be weighed up against any extra work effort and risk to delivery.
Changes to these standards are welcome, especially where there is an identifiable business
requirement. These changes will be subject to a change control process to assess the likely impact on
the project before being adopted as standards.
14.2 Software Versions
In addition to the client’s Standards documentation the following versions software will be used as the
baseline for the XYZ project. This baseline is based on the latest versions of software upon which XYZ
project is based.
• Chordiant
• Java SDK

<Project Name>
16 Approvals
The following individuals must have final approval for this Quality Management Plan. Please place your
approval by either digital signature or acknowledging your approval:
Name Role

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

Project Quality Management Plan

Recommended

Recommended

More Related Content

More from Flevy.com Best Practices

More from Flevy.com Best Practices (20)

Recently uploaded

Recently uploaded (20)

Project Quality Management Plan