By E.J. Smith
The body of knowledge regarding quality management is vast. This article is intended to give the project manager, and other key project stakeholders, preliminary insights to the importance of Quality Management in its relationship with Project Management. Readers are encouraged to reference, A Guide to the Project Management Body of Knowledge (4th ed., The Project Management Institute) for further information.
__________________________________________________
The ability of a project manager to irrefutably demonstrate that a project has met product requirements is predicated on how well the product’s requirements were defined in the first place.
__________________________________________________
Project Quality Management Overview
Quality is defined as fitness for use and adherence to requirements. Both conditions must be met to achieve quality. Fitness for use is determined, ultimately, by the business customer. The project sponsor is responsible for determining what will satisfy the business, and commissioning the proper project to create it. However, even if a project completes on time, on budget and produces exactly what was requested (i.e., adheres to requirements), it will still be considered a failure if the business customer does not perceive value in what the project produced (i.e., fitness for use).
Adherence to requirements is the responsibility of the project manager. The act of proving whether requirements have, or have not, been met is called validation; and it is typically accomplished via observation and measurement. When requirements are correctly defined, validation can be achieved regardless of who performs the validation activities, or how many times they are repeated. Conversely, when requirements are not well defined, inconsistent test results, arguments, misaligned expectations, dissatisfied stakeholders and perceptions of failure are more likely to result.
Quality Requirements
Quality planning involves ensuring requirements are defined in a manner that facilitates objective validation, rather subjective opinion. Reliably defined requirements are said to be SMART when they share the attributes of being: Specific, Measureable, Agreed upon, Realistic, and Time bound.
- Specific
- Terms like fast, user friendly, and intuitive are examples of nonspecific requirements’ attributes. These are called "fuzzy" requirements because they are unclear and therefore open to interpretation (Read: subjective). Specific attributes objectively define what constitutes fast, friendly and intuitive in an unambiguous manner.
- Measureable
- This speaks not only to the ability to measure, but also to how we interpret the results of the measurements we make. In other words, “measurable” implies the application of metrics. If measurements will be made in non-standard units (or there is more than one standard!) the quality plan must define the units of measure and how results are to be interpreted (meaning). An example might be Transactions per Second. This requirement should specify exactly what constitutes a transaction (beginning, end, size, contents), how the rate of processing will be measured and the thresholds for acceptance.
- Agreed upon
- A requirement is of little use if key stakeholders do not agree if indeed it is a requirement, or whether it has been properly defined. This is why requirement documents require signature approval from at least the sponsor and project manager.
- Realistic
- This is perhaps the most contentious of the five criteria. Sponsors and/or customers may know what they want, but they may also lack an adequate appreciation of what is involved to produce what they want. It is up to the project manager to determine what can be accomplished within well defined constraints (Time, money, resources, etc.). Estimating methods, negotiation and compromise are tools for defining realistic requirements. If there is a requirement for something too uncertain to reliably estimate, consider adding a feasibility phase to the project’s lifecycle to determine the viability of such requirement(s).
- Time bound
- This requirement attribute addresses when the requirement will be satisfied, and is documented in the project schedule.
Quality Standards, Quality Assurance and Quality Control
A customer requirement becomes a Quality Standard when it has been SMART-ly defined, documented, and placed under formal change control. After Quality Standards are baselined in this manner, the next step is to define the Quality Control (QC) and Quality Assurance (QA) activities used to meet the Quality Standards. We will use the following definition for QC and QA:
QC measures performance against quality standards and may lead to corrective actions based on the findings.
QA ensures the efficacy of QC by examining if we are measuring the right things, properly and interpreting the results accurately.
Use the following checklist of questions as a basis for designing Quality Control activities:
- Does each Quality Standard have a QC activity assigned to it?
- For each QC activity:
- What will be measured?
- How will it be measured?
- Who will perform the measurement activity (project team, customer, third party …)?
- How many times will the activity be performed (once, in batches, periodically)
- Where will the activity be performed (location, environment ...)?
- When will the activity be performed (upon delivery, event triggered, project end …)?
- Under what environmental conditions?
Use the following checklist as a basis for designing Quality Assurance activities:
- Who will observe / verify the activity results?
- How will the test environment be configured, and who will create and validate the environment?
- If sampling, how do we know the samples accurately represent the population?
- What constitutes “accurate”, and how will we know if the data meet this criterion?
- Who will sign the technical and/or managerial acceptance documents?
- How do we determine if a QC (or QA) initiated actions are producing desired results?
Quality of Project Management
__________________________________________________
Just as a product has requirements, so too do projects.
__________________________________________________
Although the discussion thus far has focused on the quality of a project’s product deliverables, it is equally important that quality management be applied to a project’s deliverables. The assertion here is: “Projects managed in a quality manner will produce quality results.” Among the subsidiary plans that comprise a comprehensive Project Plan, the Quality Management Plan addresses both product and project requirements.
All projects have requirements and deliverables that are not features of the product itself. Rather, such requirements and their corresponding deliverables support the management of the project. One approach to identifying project management requirements is to review the nine project management knowledge areas and consider the inputs and outputs involved. One example concerns the requirements of Risk Management: One of the nine Project Management Knowledge Areas defined in the PMBoK.
Example 1
A good practice is to identify and document project risks in a Risk Register. This register typically contains information on the nature of identified risks, risk priorities, risk owners and any risk response plans in place or underway. Because risks come and go throughout a project’s life cycle, it is also good practice to periodically convene the project’s key stakeholders to review and update the risk register. Two project management quality requirements are clearly identifiable here are:
- A risk register, and
- Periodic risk review meetings to maintain the register.
Quality control for these requirements is addressed by placing activities for risk register creation and maintenance, and periodic risk review meetings into the project schedule. These are the QC activities necessary to ensure project management adheres to the requirements of the prescribed risk management processes. But how do we know these activities are effective? Through Quality Assurance. QA activities would focus on ensuring the meetings actually occur, the risk register is actually maintained and the QC activities are not only occurring as planned, but are actually doing an adequate job of managing risk. The first two of these QA activities involve auditing; the third concerns the efficacy of the other two, i.e. are those activities producing the desired results? Suppose during the execution phase of the project audits indicate risk meetings are occurring as planned and the risk register is being well maintained. Suppose further it’s become apparent the project is encountering too many risks that should have been identified in the planning phase, but alas, were not. The QA response may be to increase the frequency of the risk management meetings and/or to remediate with additional risk planning to identify what should have been identified prior to execution.
Similar QC and QA activities can be formulated based on each of the knowledge area’s processes as well as various essential PM functions.
Example 2
A second example concerns the application of stage gates between project life-cycle phases. As a project transitions from, say, the planning phase to the execution phase the project schedule should contain review activities to ensure all previously due project deliverables have been properly created and approved. The following checklist can be used as a basis for such a quality activity:
- Has the project charter been reviewed for accuracy and signed by all signatories?
- Have all the product requirements been identified?
- Do all the product requirements meet the SMART criteria?
- Does each product requirement have at least one quality standard to measure?
- Are there adequate QA activities to prove the QC activities are effective?
- Have all tasks for creating the product and managing the project been identified?
- Have all tasks been scheduled using an appropriate technique and expertise?
- Have all the necessary resources been secured and committed to the project by their managers?
- Is the budget secured?
Although this is not a comprehensive list, it illustrates how QA/QC activities can be applied as checkpoints throughout your projects’ life cycle.
Conclusion
By now the criticality of quality management to the success of projects should be evident. Without well-defined and baselined requirements, project success remains vulnerable to subjective opinions. The very act of creating SMART requirements invariably surfaces where different understandings may exist early in the project lifecycle. This greatly reduces the risk of the customer expecting something different from what was delivered, after all the budgeted resources have been expended. For all of these reasons (and more) a project quality plan is an essential part of any professional project plan.
Footnotes
1. More commonly referred to as the PMBoK. Pronounced, “Pim-bok”.
2 Variations exist.
3 The nine project management knowledge areas are: Integration, Scope, Time, Costs, Quality, Risk, Communications, Human Resources and Procurement management. See “A guide to the Project Management Book of Knowledge”, 4th Edition for a complete list of the process involved and their associated inputs and outputs.