Introduction to Quality Gate Review Checklist

Step 1
I. Objectives
II. How to use
1. Work flow
- To verify objectives of project stages/milestones/processses against project target and plan
- To evaluate project performance against project target and plan
2.2 Steps
Develop Quality Gate Review Checklist
Project QA Lead customizes Quality Gate Review Checklist specific for the project based on customer requirement, WO, QA Plan and the standard Quality
Gate Review Checklist. This activity shall be conducted within 15 days from the Project Start Date.
- Mark N/A for items that are approved to be waiver for the project. Reason for N/A must be recorded in column "Observation" and correspondent
tailoring/deviation must be recorded in FI and be reviewed and approved by authorized persons in accordance with Guideline_Process Tailoring prior to
the implementation.
Quality Gate Review
A
s
s
i
g
n
e
d

Q
A
P
r
o
j
e
c
t

Q
A

L
e
a
dCustomize Quality
Gate Review
Checklist
Conduct Stage/
Milestone
Accomplishment
Verification
Evaluate Project
Performance
Summarize
Quality Gate
Review Result
Report Quality
Gate Review
Result
Get confirmation
on issues and
corrective actions
Log issues to
PMS
Follow-up
(Process_Correction)
Assign & Train
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 1/19
Step 2
Step 3
Step 4
Step 5
Step 6
Conduct Stage/Milestone Accomplishment Verification
Evaluate Project Performance
Summarize Quality Gate Review Result
Report Quality Gate Review Result
Project QA evaluates performance of the defined stages/milestones/processes using the sheet "Performance Evaluation".
Project QA summarizes result of quality gate review, identify issues and suggestions using the sheet "Quality Gate Summary Report".
- Record your detail observations/comments in 'Observation' column
Follow up
Project QA sends Quality Gate Review Result to Project QA Lead, SM, PM and other relevant persons to get confirmation on issues and corrective actions.
If there is a conflict of opinion, escalate the issue to Project QA Lead, QA Lead for resolution.
Project QA logs issues detected into PMS and follow up the issues & corrective actions to closure in accordance with Process_Correction and
Process_Prevention. Escalate to appropriate QA Leader, QA Manager when the issues not resolvable with the responsible people or when the issues are
pending more than 1 week from the deadline.
Note: It is recommended to insert additional checked items at BOTTOM of the checklist. Other checklists could be combined with the Quality gate review
checklist to verify specific items of the stage/phase/steps.
Project QA verifies accomplishment of the defined stages/milestones/processes using the checklist in sheet "Milestone Verification", then mark 'OK', 'NOK',
or 'NA'
- 'OK' means that the item content is in the project work, mandatory requested for checking, and is satisfied
- 'NOK' means that the item content is in the project work, mandatory requested for checking, and is
NOT satisfied
- 'N/A' means that the item content is out of the project work, therefore it does not need checking
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 2/19
III. Guideline for Project Performance Evaluation
1. Purpose
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 3/19
Medium
Cosmetic
If actual value is better than or equal to the target.
actual value is worse than the target but there is no impact to the next step/phase/stage.
For example: actual project size is lower than planned.
If its actual value is worse than the target and it will affect to next step/phase/stage
quality.
-Quality evaluation
-Cost evaluation
- Delivery evaluation
- Conclusion
Target Value: the information could be gotten from PM. It is normally recorded in standards supplied by
Customer or Work Order, Project Plan
2. Guideline
Purpose of the document is to provide guidance and template for Project Performance Analysis Report. The
report is usually prepared by PM and QA at the end of critical steps/phases/stages to thoroughly evaluate
project performance at the current step/phase/stage before making decision of moving to next
steps/phases/stages or not and define necessary actions to be taken later on. It describes project performance
in a quantitatively manner using pre-defined metrics.
Normally, a project performance analysis report contains four main parts as following:
- Header of report
- Suggestions
2.1Header of Report
2.2Quality Evaluation
This part provide brief information of project and the report
Analysis:
Serious
1) Comparing actual performance against target for quality related metrics (defect rate, number of
defects found, % of defect detected, leakage, etc), you can evaluate whether the project performance
reaches the target or not. If deviation between the actual performance and the target >10% (this
threshold could be customized by projects), causal analysis/explanation is required.
Actual Values: the information is gotten from PM, or gotten from project records (DMS or equivalent - Defect)
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 4/19
Analysis:
Comparing actual performance against target for schedule related metrics (Timeliness, schedule
deviation, etc), you can evaluate whether the target is satisfied and the project performance reaches
the target or not. If deviation between the actual performance and the target >10% (this threshold could
be customized by projects), causal analysis/explanation is required.
Serious
Medium
If actual value is better than or equal to the target.
Actual value is worse than the target but there is no impact to the next step/phase/stage.
For example: actual project size is lower than planned.
Analysis:
Comparing actual performance against target, you can evaluate whether the project performance
reaches the target or not. If deviation between the actual performance and the target >10% (this
threshold could be customized by projects), causal analysis/explanation is required.
Serious
3) Analyze root causes of defects, then identify the most common defect causes => determine
action/solution to be taken for next period.
2.3Cost Evaluation
If actual value is better than or equal to the target.
Target Value: the information could be gotten from PM. It is normally recorded in standards supplied by
Customer or Work Order, Project Plan
Actual Values: the information is gotten from PM, or gotten from project records (Effort Efficiency, Effort
Effectiveness, Productivity, Effort distribution, etc).
Medium
Actual value is worse than the target but there is no impact to the next step/phase/stage.
For example: actual project size is lower than planned.
Cosmetic If its actual value is worse than the target and it will affect to next step/phase/stage quality.
2.4Delivery Evaluation
Target Value: the information could be gotten from PM. It is normally recorded in standards supplied by
Customer or Work Order, Project Plan
Actual Values: the information is gotten from PM, or gotten from project records (Project schedule - Delivery)
2) Identify common defect type and location using Pareto chart
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 5/19
Cosmetic If its actual value is worse than the target and it will affect to next step/phase/stage quality.
Basing on project performance evaluation result, the author has suggestions to the project. Action/solution is
mandatorily required if evaluation result is "Not pass"
2.5Conclusion
Basing on evaluation result on project performance in term of Q-C-D, the author has to make a conclusion on
project performance in the report period. The project performance could be summarized in "Traffic Light
Reporting" format to provide quick snapshots to the reader on the project status and drive the readers to pay-
attention on important issues.
2.6Suggestions
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 6/19
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 7/19
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 8/19
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 9/19
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 10/19
Analysis:
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 11/19
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 12/19
a.
[x] Satisfied [] Un-Satisfied [] Other
Enter rationale to derive to the conclusion "Not Achieved" or "Other"
b. Project Performance
Quality Cost
Delivery
No Project Code Customer PM AM QA
Raised
Week
Issue Description Cause Impact
<Add more row if needed>
Note: Manadatory to fill
<List issues together with your suggestions. It is mandate for "Un-Satisfied" of Stage/Milestone Accomplishment or Project Performance highlighted in RED >
1. Conclusion
2. Issues & Suggestions
<Summarize conclusions get from Milestone Verification & Performance Evaluation here>
Stage/Milestone Accomplishment
Conducted by
Quality Gate Review Report
<dd-mmm-yy>
<Basic design of Batch 1 from
10-Mar-2010 to 02-Apr-2010>
Report Date
Report Period
Project Code
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 13/20
Severity
Action requested by
QA
PIC
Target
Deadline
Status
Actual
Action
Actual Date Note
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 14/20
Report Date
Report Period
ID Assessment Observation
Does the next plan of processes, resource,
effort, schedule, quality ensure good quality
of its outputs?
Verification of Stage/Milestone Accomplishment
Have objectives/exit criteria of the
stage/milestone/process completely
satisfied and obtained approval of
appropriate person?
Criteria #1
Criteria #2
Criteria #3
Check Item
Is quality of inputs of the next
stage/milestone/process good enough to
ensure good quality of work product of the
next stage/milestone/process?
Project Code
Conducted by
<Basic design of Batch 1 from
10-Mar-2010 to 02-Apr-2010>
0
0
Reference
<dd-mmm-yy>
Are work products of the
stage/milestone/process completed?
Work product #1
Work product #2
Work product #3
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 15/19
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 16/19
Report Date
Report Period
No. Unit Target Actual Deviation
1 <Wdef/KLOC>
2
1.2 Defect Analysis
<Type all descriptions about the chart into this part>
- Defect type having the biggest number of defect is<Coding
logic>..., most of which belong to ..<medium> severity.
- Following ..<coding logic> is <business logic>.
.etc.
- The metric <Unit test Defect Rate>does not reach/reaches
committed Quality target. The deviation is .<40%>..
The main reasons for this are:
+ Process: <Unit Test Case is not well modified to suit with JUnit &
this project specific business>......
+ Humance Resource:.<7/10 team members are newbie with Unit
Test & with Java>.
+ Project Management:......<Training class about Unit Test for newbie
was not conducted>......
+ Others: .....<Business of customer's system is very complex to create
good Unit Test Case while system documents that customer supplied
did not contain enough information for development>....
< Type evaluation - root cause for metrics that have been filled
avbove>
<Insert "Defect Distribution by Type" & Defect Ditribution by Module" Charts here. Data can be
extracted from DMS databse>
<Insert Pareto Charts of Defect Cause here. Data can be extracted from DMS databse>
1.3 Defect Cause Analysis
1. Quality Evaluation
1.1 Metrics
Metric Remark
<Unit test Defect Rate>
Project Performance Evaluation Report
Project Code 0 <dd-mmm-yy>
Conducted by 0 <Basic design of Batch 1 from 10-Mar-2010 to 02-Apr-2010>
0
100
200
300
400
500
600
700
800
Fatal
Serious
Medium
Cosmetic
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 17/19
No. Unit Target Actual Deviation
1 #DIV/0!
2 #DIV/0!
No. Unit Target Actual Deviation
1
2
No.
1st Committed
Delivery Date
Last Committed
Delivery Date
Actual Delivery Date
1
2
3
3.3 Analysis
<Enter analysis here>
Deliverable Remark
2.2 Effort distribution (could be referred to FI/Effort)
2.3 Analysis
<Enter analysis here>
3. Delivery Evaluation
3.1 Delivery Metrics
Metric Remark
3.2 Deliverable status (could be referred to Project schedule)
- The metric <Unit test Defect Rate>does not reach/reaches
committed Quality target. The deviation is .<40%>..
The main reasons for this are:
+ Process: <Unit Test Case is not well modified to suit with JUnit &
this project specific business>......
+ Humance Resource:.<7/10 team members are newbie with Unit
Test & with Java>.
+ Project Management:......<Training class about Unit Test for newbie
was not conducted>......
+ Others: .....<Business of customer's system is very complex to create
good Unit Test Case while system documents that customer supplied
did not contain enough information for development>....
< Type evaluation - root cause for metrics that have been filled
avbove>
Metric
2. Cost Evaluation
2.1 Cost Metrics
Remark
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 18/19
Quality Cost Delivery
<List issues together with your suggestions>
No. Request to Due Date
1
2
4. Conclusion
<Enter the conclusion here>
5. Suggestion
Issue Request for Action
10e-CL/PM/HDCV/FSOFT v2/3 Internal use 19/19