4squareviews

Before we discuss this planning process for the quality management knowledge area, let us make sure we are clear that quality is a constraint that covers the correctness of the work, as supposed to the scope that covers the completeness of the work.   Correct as compared to what, you may ask?   Correct as compared to the requirements as set forth at the very beginning of the project, which come from customers for an external project or the project sponsor for an internal one.

Like any other planning process, the process is designed to create guidelines and procedures on how to do all of the OTHER processes in the knowledge area, which are going to be contained in the Quality Management Plan as an output of the process.

Here are the inputs to the process:

8.1.1 Plan Quality Management:  Inputs

8.1.1.1 Project Charter

The project charter contains the high-level project description (sometimes referred to as the “statement of work”) and the product characteristics which are the technical requirements.   There may also be other requirements listed in the project charter, such as any requirements for the final product of the project to be approved by the customer or sponsor (as part of the Validate Scope process).

8.1.1.2 Project Management Plan

Here are the components of the project management plan which may be inputs to this process.

• Requirements management plan–the output of process 5.1 Collect Requirements, this shows how the requirements will be identified, analyzed, and managed throughout the project.   The requirements are the highest level of the scope.
• Scope baseline–the requirements are broken down into the deliverables in the project scope statement, and these in turn are broken down into the level of work packages in the Work Breakdown Structure or WBS.   The project scope statement, the WBS, and the WBS Dictionary, which contains information on the other constraints that relate to each work package (duration and cost estimates, for example), are all part of the scope baseline.
• Risk management plan–output of process 11.1 Plan Risk Management.   Information from the risk management plan is used together with the quality management plan to successfully deliver product and project success.   Quality is measured by metrics which measure the likelihood of defects and these risks of a defectneed to be considered in the cost of quality, which compares the cost of doing quality control measures with the cost of NOT doing them (i.e., allowing a certain level of risk of defects).
• Stakeholder management plan–output of process 13.2 Plan Stakeholder Management.   This contains the plan on documenting the stakeholders’ needs and expectations that contribute to the requirements for the product and project to be a success.

8.1.1.3  Project Documents

• Assumption log—output of process 4.1 Develop Project Charter. May contain assumptions and constraints regarding quality requirements.
• Requirements documentation (including requirements traceability matrix)—may include project and product quality requirements, as well as tests required to verify those requirements.
• Risk register –may contain information on threats and opportunities that impact quality requirements.
• Stakeholder register—helps identify stakeholders who have a particular interest or impact on the quality requirements.

8.1.1.4 Enterprise Environmental Factors

Among the enterprise environmental factors that may influence the quality requirements for the project are the following:

• Governmental agency regulations regarding health and safety
• Standards related to quality that are specific to the application area

8.1.1.5 Organizational Process Assets

• Organizational quality management policices, procedures, and guidelines
• Quality-related templates
• Historical databases and lessons learned repository from previous similar projects

The next post will cover the tools and techniques of this process.

Filed under: Uncategorized |