This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The quality management approach policies will include the teams quality assurance e.g. type and frequency of reviews, planned measures, etc. and control e.g. measurements to utilize and improvement actions activities during the project, as well as a description of the quality strategy or expected quality performance measures. The project management team will schedule and manage quality reviews and incorporate process improvements. Finally, the project management team will coordinate the independent quality management team.
After gaining agreement on the QM approach, the project manager will incorporate any quality management activities and milestones into the project schedule, so that project members can accommodate for any additional labor, expense, time, etc. necessary to achieve the defined quality objectives.
3.1.2. Create the Quality Metrics and Checklists
Once the project management team has defined the quality performance objectives, they create the quality metrics and checklists necessary to measure the compliance of project products and services defined in the project charter. For instance, a project management team will create a checklist of major milestones and activities of each project phase to complete its phase completion review. The project team will create "Readiness" and "Go-Live" checklists to document cutover to the live system. Quality metrics will be developed as part of the training, data conversion and testing plans to measure the success of these activities and guide improvement in processes as they progress.
3.2. Quality Assurance
3.2.1. Perform Quality Reviews
For the HRIS Implementation Project, there will be three primary types of quality review processes.
Project Management and Team Reviews (Peer Reviews) - Processes to check quality are built into the day-to-day activities of the project. The project management will check quality of deliverables throughout the project. The project team will monitor its performance through self and peer review activities.
Project Quality Reviews - Resources that are independent of the HRIS project team will perform periodic reviews of the project team deliverables. These resources will likely be more technical in nature and perform independent checks of PeopleSoft set up and testing results.
IV&V and Independent Reviews - Independent Verification and Validation will occur once during each major phase of the project.
The goal of these processes is to provide objective review of the product and to make sure that they are within acceptable tolerances, as defined in the plan.
The following table provides a description of the types of reviews, resources and frequency of occurrence.
Quality Review Processes
Project management team and project team members
Project Quality Reviews
Matrixed group composed of audit groups, consultants and VCCS resources
Specific Deliverables & During Testing
IV&V and Independent Reviews
Each phase of the project During testing and project close out phases.
126.96.36.199. Peer Reviews
An informal peer review process is used on selected areas of the project based on complexity or significance of a specific project deliverable. These reviews are conducted by other members of the project team to ensure all quality standards and guidelines are being met. This will include:
Review of project management plans and documentation by members of the project management team.
Review of technical specifications and code by other developers on the project team.
Review of functional specifications, design documents and configuration documents by other members of the functional teams.
188.8.131.52. Project Quality Reviews
Project quality reviews represent an independent review of the project's processes, work products and deliverables. The project quality audit will be conducted by the Project Quality Assurance Team to ensure an independent evaluation of all work and processes.
Review the project plan documents and project control procedures to determine that ISO 9000 standards and guidelines are met.
Review the coding, testing and configuration work products and deliverables to determine that coding standards are followed and that deliverables meet specifications as defined by the project.
184.108.40.206. IV&V Reviews
A periodic IV&V and independent reviews of the project will be conducted to determine that the project is meeting the set standards for a high complexity project.
3.2.2. Implement Continuous Improvement
The project management team will continuously examine the project's processes and deliverables to isolate possible problem sources and locate opportunities for improvement. Potential corrective actions to reduce deviations from quality criteria and remove non-compliance issues could include:
Rework of deliverables
Review standards and guidelines in order to revise portions of it is inadequate for the work being performed
Changes in resource allocation
Providing additional training for team or individual members
Clarification of ambiguous tasks
The project management team will review any corrective actions with regard to their potential impact to schedule, budget, groups, and affected individuals. Assignment of corrective action ownership will vary depending on the issue / work stream as governed by the issue management process.
If such a review identifies that a quality measure for a process is not achievable under the limits of the project's defined scope, a Change Request may be initiated.
3.3. Quality Control
As mentioned in the quality planning activities, project management team defines the metrics used to measure the quality of the project's processes and deliverables. Once project execution begins, the project management team is responsible for gathering the quality measures needed to verify that deliverables are of acceptable quality. To ensure quality will remain a focus of the project team, the status of the quality activities will be reviewed in each of the bi-weekly project management meetings.
The following table defines the high-level quality control measures for the project.
QC Metric / Criteria
Phase completion check list (milestones & activities)
Corrective Action Plan
Deliverable review check list
Deliverable sign off and approval
Training Readiness Review
Training evaluation rating (>x on a scale of 5)
Modify training, change resource
Requirements traceability matrix
Completion and sign off of acceptance test scripts
Defect management process change and Corrective Action
Employee records converted accurately
Completion and sign off of data conversion
During conversion and go-live
Corrective Action Taken
Project Close Out
Project Closure Agreement
Lessons Learned Archive
Note: Some example checklists are included in the appendix for information only. Specific deliverable and phase review checklists will be developed to support the project and document quality.
Appendix A - Deliverable Audit Checklist
Quality Management - Deliverable Audit Checklist
Deliverable Audited: ______________________________ Date: ___/___/___
Is the deliverable adequately described?
Correctly depicts the deliverable or item being described
Is the deliverable consistent with other deliverables (no contradictions, terminology mismatches, etc.)?
No statement or representation in one deliverable contradicts another deliverable
Terms, acronyms, abbreviations mean the same thing in all deliverables
Given item or concept is referred to by the same name
Is the deliverable complete (covers all required requirements) and traceable?
Every item in a set has been dealt with in the deliverable (e.g., solution covers a set of requirements if every requirement has been dealt with in the solution)
Is the deliverable feasible (capable of being carried out)?
A given concept, set of requirements, design, test, etc. violates no known principles or lessons learned that would render it impossible to carry out
Is the deliverable testable (objective and feasible tests can verify requirements)?
Objective and feasible test can be designed to determine whether each requirement has been met
Are test cases, procedures, data, and results adequate to ensure requirements are satisfied?
Test cases cover all applicable requirements or design decisions, specify the input to use, expected results, and criteria for evaluating results
Test procedures specify specific steps
Test data enables execution of planned tests cases and procedures
Results describe test results and show that criteria have been met
Test results show that the item under test passed all tests
If the deliverable is not testable, for example the look and feel of a GUI, are appropriate demonstrations and/or inspections identified?
Demonstrations and/or inspections can be defined and controlled to determine if each qualitative requirement has been met
Is the deliverable being developed or produced in accordance with defined plans and standards?
Shows evidence of having been developed in accordance with the approach described in applicable plans (e.g., follows design standards)
Is the deliverable internally consistent (no internal contradictions)?
No two statements or representations in a deliverable contradict another
A given term, acronym, abbreviation means the same thing throughout the deliverable
A given item or concept is referred to by the same name or description
Are deliverable delivery requirements (format, markings, etc.) being met?
Format, markings, and other provisions of the contract are met
Does the deliverable present a sound approach?
Represents a reasonable way to carry out the required activities
Is the deliverable understandable and at the appropriate level?
Understandable by the intended audience
QC Closure: _________________________________ Date: ___/___/___
appendix b - close out Phase checklist
Plan to Resolve
Have all activities, tasks, and subtask been completed as specified in the baseline project plan?
If the answer to 1 is No, is there a plan to complete these tasks?
If the answer to 1.1 is No, is there an impact on the project delivering the product, good, or service for which it was chartered?
Have all issues raised during the course of the project been closed?
If the answer to 2 is No, is there a plan to close out these issues?
Has all documentation supporting the transfer of the project deliverables to operations been completed?
Have planning and coordination meetings been held with operations to insure a smooth transition of responsibility?
Has the project met or exceeded performance goals established in the project performance plan?
If the answer to 5 is No, is there an impact on project deliverables?
Have all deliverable tests been completed?
Did the product deliverables meet the acceptance criteria established in the project plan?
Has a user acceptance document been completed?
Has the authorized user authority signed off on acceptance of the deliverables?
Were there any conditions or exceptions identified in the user acceptance document?
If the answer to 7.2 is Yes, is there a plan to satisfy the conditions or exceptions?
If the answer to 7.3 is Yes, is there a need for additional resources or time to satisfy the users conditions? If so, identify the needs in the comment column.
Is a plan in place to conduct the project closeout task?
Have the project closeout tasks been assigned?
Has a date been established when the Project Closeout Report will be completed?
Is there an expectation of administrative or logistics issues during project closeout?
Approved by the Project Sponsor:
<Project Sponsor Title>