Apply Quality Policies and Procedures

During the project design and planning stages, the key stakeholder requirements, including the client/sponsor, organisational, industry standards and regulatory requirements, are established and documented in the project plan. After approval, these are baselined as the quality standards that must be met.

All quality processes to be implemented must be in compliance with the quality standards and requirements established. The activities to be performed as part of quality management, namely project quality assurance, must adhere to the standards and guidelines in place.

Quality Standards

Quality standards are documents that provide specifications, requirements, guidelines, or characteristics. These documents are used to ensure that the materials, products, processes, and services are fit for their purpose.

Maintaining quality standards helps businesses to:

• satisfy their customers’ quality requirements
• ensure the safety and reliability of their products and services
• define and control internal processes
• meet environmental objectives.

The following table shows how quality standards apply at each stage of the project life cycle:

Quality Guidelines

Quality guidelines are assurance measures that all aspects of your project must be at a consistent level.

The ISO 10006 standard provides guidelines for quality management in projects. It covers the following main areas:

• quality management systems in projects
• management responsibility
• resource management
• product realisation
• measurement, analysis, and improvement

Other specific guidelines may be embedded in your organisational policies and procedures and in the specific project documentation, for example, in the quality management plan. The quality plan will define the acceptable levels of the project and process quality and the corrective action for non-compliance of processes or products.

Implementing Quality Assurance

As briefly defined in the previous section, quality assurance refers to managing the quality of the processes involved in meeting the project outcomes. It is a part of quality management that is focused on providing confidence that quality requirements will be fulfilled. Quality assurance concentrates on measuring or assessing the quality of the project processes implemented in creating the deliverables, both products and services.

A strategy must be developed for embedding quality assurance into all aspects of the project and all stages of the project life cycle. Quality assurance is not something that only happens at the beginning or end of the project but must be continuous throughout. The strategy and processes for quality assurance will be established during planning and included in the project plan. They must then be implemented and followed.

Quality Assurance Process

Quality assurance ensures that there are procedures in place to monitor the project processes and guarantees that quality standards are met on an ongoing basis. Everyone involved in the project has a responsibility to implement and follow quality assurance procedures. In doing so, you will contribute to the success of the project by reducing risk, cost, and time and increasing efficiency.

Processes must be implemented at all stages of the project to:

• assess the quality of products/services
• report non-compliance with quality standards
• identify causes of non-compliance and address them

It is much more cost-effective that an issue is identified and corrected during the quality assurance processes than to be left out until the end and have non-compliant end-products/services.

There is a range of ways by which you can perform quality assurance, depending on the quality policies and procedures established in your quality management plan. Some of these processes are as follows:

Quality audits

Quality audits are systematic reviews of project activities, processes, and systems to recognise their compliance with the quality requirements set in place. This process also takes place with the aid of experts who review the process and procedures and offer constructive feedback to rectify any issue or shortfall they discover.

A system of reviews may be in place where another team member or designated quality reviewer checks the product or service and completes their own quality checklist. The more times something is validated by different people, the less likely that defects or faulty compliance with standards will slip through. Additionally, at the end of each stage or at designated milestones, objective and independent audits might be conducted by either internal or external auditors.

Some of the key requirements for an effective quality audit are:

Click on the requirements to read more about each.

Problem-solving

This entails finding solutions for issues and challenges identified. Problem-solving methods generally include:

• Defining the problem
• Identifying the root cause of the issue
• Generating a set of possible solutions
• Identifying the best solution from the roster
• Implementing the solution
• Verifying the effectiveness of the solution

This process can be facilitated by utilising problem-solving tools such as the cause-and-effect diagram.

Documenting and recording

An essential part of quality assurance is ensuring that there are clear processes that detail how to go about documenting, reporting, and acting on identified non-compliance issues. It is not sufficient to simply identify an issue; it must then be brought to the notice of someone with authority to do something about it. Issues of non-compliance must be resolved quickly to avoid wasting time and resources and potentially derailing the entire project.

Identified issues are usually reported via the issue register. As part of this process, an issue register should also include who the issue has been assigned to for resolution. Issues may also be raised informally through conversations, email messages, and phone calls or as part of regular team meetings. In all cases, it is crucial that as soon as an issue is identified, a team member must be assigned the responsibility of acting to resolve it.

Some of the key requirements for effective quality planning are:

Click on the requirements to read more about each.

Quality planning

Although no initial quality planning must take place during the quality assurance process, this process heavily relies on the quality standards and guidelines set in place in the quality plan. All quality assurance processes to be performed must be in conformance with the established quality policies and procedures.

The initial quality management plan may be modified and updated according to the actual results of the quality assurance process.

Your own organisation may have a defined list of quality assurance activities based on established policy and procedures. The quality assurance processes you perform and the resources you access must be in compliance with quality standards and guidelines applicable to the project.

Some of the key requirements for effective quality planning are:

Click on the requirements to read more about each.

As already briefly mentioned before, the quality management plan your project team developed must contain the tools and techniques that you will use to assure that the project processes and outcomes are in conformance to the quality standards and guidelines put in place.

These tools and techniques aid in maintaining the quality of the project processes, more specifically by:

• Identifying the root cause of defects and risks identified in the quality assurance process
• Determining the level of variance or non-conformance of project process
• Showcasing the relationships between the variables involved in the project processes.

Quality Management Tools and Techniques

The following are some of the most popular tools and techniques used in quality management:

Benchmarking Standards

The specifications of many projects are bound by benchmarking standards. These standards may be dictated by legislation through Federal, State, or Local Government regulations. Many standards are dictated by industry bodies or through Standards Australia. Other benchmarking standards relevant to your organisation may also apply.

Benchmarking standards allow the comparison of project quality against other similar projects, organisations, or industries. They give an indication of ‘best practice’ and provide models for improvement.

Examples of benchmarking standards include:

• All household electrical appliances that plug into a wall must be designed for a 240-volt power supply specified under AS/NZS 3112
• Local Council restrictions on how close a building can be built in relation to the property’s boundaries
• An organisational style guide to which all internal documents must adhere.

Brainstorming Sessions

A brainstorming session is an informal group discussion activity wherein the members convene and are presented with a scenario or problem which they have to come up with a range of solutions for in a free-flowing manner.

Brainstorming sessions allow the collection of multiple points of view and are useful in quality management for capturing a range of ideas and in finding solutions.

A very effective brainstorming technique is known as ‘Osborn’s method’. In the Osborn method, a brainstorming session is based on four general rules:

• Focusing on quantity – the higher the number of ideas generated, the greater the chance of producing an effective solution.
• Withholding criticism – put out as many ideas as possible, regardless of how outrageous some of them may seem at the time. Leave the criticism until later when you start shortlisting the ideas.
• Welcome unusual ideas – this encourages creativity and thinking outside the box. Often, these unusual ideas lead to innovative and plausible solutions.
• Combine and improve ideas – often, ideas on their own do not make much sense, but when combined with other ideas, they can form solutions.

This method works well provided the facilitator of the session presents the group with clear and specific questions. Sessions addressing multiple questions are often inefficient.

Cause-and-Effect Diagrams

Cause-and-effect diagrams, also known as Ishikawa or fishbone diagram, are useful for identifying risks and problems in quality management by tracing the problem back to its root cause. Once the root causes are determined, they can be sorted into categories to aid in determining and developing an improvement plan to resolve the problem.

Here is a sample cause-and-effect diagram:

Control Charts

Control charts, also called ‘Shewhart’ charts, run charts, or process behaviour charts, are used to study changes in a process. These are also useful in monitoring process stability and control of a particular project.

Control charts are used to statistically measure the quality characteristics of a process under control. This is based on statistical analysis where a centre line is drawn for the mean of the output, then an upper control limit and a lower control limit is created either side of the centre line. The process is then measured over a period of time, and the results plotted on a graph. The graph is then analysed to test the stability of the process and also identify any cycles of errors.

Here is a sample control chart:

Histograms

These are graphical representations showing a visual impression of the distribution of data.

Analysing the patterns shown in the histogram can contribute to quality management by pinpointing variations in quality.

Here is a sample layout of a histogram:

Flowcharts

Flowcharts, also referred to as process maps, show the sequence of stages or procedures involved in a process. Flowcharts visually show the activities, steps, paths, and over-all process as a series of shapes with arrows in between them to indicate the workflow.

A common convention in flowcharting is to use rectangular boxes to represent tasks, and diamond-shaped boxes to represent decision points where the flow can split into two or more directions.

Here is a sample basic flowchart:

Scatter Diagrams

Scatter diagrams, also known as scattergrams, or scatter plots, is a cause analysis tool that utilises points in a graph to represent data.

They show the relationship of pairs of numerical data with one variable plotted on each axis. It is represented as a distribution of dots comparing two variables. If the two variables are completely independent, you would expect the dots to be evenly distributed randomly across the graph. If there is a strong relationship, though, the graph will show a straight line or a mathematical curve.

Scattergrams reveal the relationship between the variables involved in the process. They also aid in predicting how a change in one variable or element will affect and change the other.

Here is a sample scatter diagram:

Pareto Diagrams

Also called Pareto charts or Pareto analysis, Pareto diagrams are graphical representations of the frequency of risks and problems and their cumulative effects in the process or system.

Similar to a histogram, a Pareto chart includes a line over the graph to indicate the cumulative distribution of results. However, unlike a histogram, a Pareto diagram orders the data by frequency — from largest/highest to smallest/lowest. Doing so facilitates the prioritisation of issue resolution that must be taken.

Pareto diagrams are useful in identifying and analysing the most frequent problems in order to focus on what is significant.

Below is a sample Pareto diagram:

Check Sheets

Check sheets, also called tally sheets, are structured checklists or forms primarily used in data collection and analysis. These are utilised when data can be explicitly observed and systematically recorded.

Check sheets help determine trends and patterns that occur in the quality management process.

Here is a sample check sheet:

Selecting and Applying Quality Management Tools and Techniques

The quality management tools and techniques that are selected for use in a project will generally be dictated by organisational policy and/or convention and by the project manager’s personal preferences. Additionally, different industries tend to recommend and adopt particular methods and techniques that are perceived to be best suited to their industry and specific context.

Each tool and technique have pros and cons, and some may be more suitable for specific projects than others. While the responsibility for selecting the tools and methods may not be assigned to everyone in the project, you will still have a part in applying them to the project.

As each quality management tool has its own function and unique data it represents, its application to ensuring quality in different projects across industries may vary. For instance, in working on a project in the business industry, specifically in a construction materials business, you may collect data regarding the quantity of positive customer feedback on the quality of the products you offer. These pieces of data can be collected for a number of consecutive years to show the progression of the effectiveness of your products.

A histogram can be used to represent that quantity and to determine the trend in the feedback, and whether the products serve their purpose through the documented years. Should there be issues deduced through the histogram (e.g. a significant decrease in positive feedback from clients), an Ishikawa diagram can be utilised to determine the cause and effect of the issue. Other tools and techniques can be applied as necessary.

When the appropriate methodologies and tools are consistently applied to assure that the project processes meet the quality requirements set in place, processes are more streamlined, issues are identified and dealt with earlier, and stakeholder satisfaction is more likely.

WATCH

The following 3-minute video provides a comprehensive presentation of how Jira can be used:

You can sign up to try Jira for free: you just need to provide an email address. There are different templates available that you can use for your project (although you can choose not to use any templates as well). Once you have your project page created, you can start adding tasks to your to-do list, assign them to individual stakeholders, add due dates, etc.

Watch

The following 12-minute tutorial can help you get started on Jira:

Quality assurance goes hand in hand with quality control. The compliance of the current project to the different quality requirements and standards is not guaranteed without performing quality control.

Performing Quality Control

Quality control is geared towards ensuring the quality of the product or services, or project deliverables. Evaluating the quality of these deliverables is based on an assessment of how well they meet the quality standards established and baselined in the planning phase of the project. Having quality standards assures the quality of work and project deliverables.

Quality control procedures might include:

• Auditing
• Testing (for example, using checklists developed in-house or from manufacturers, industry bodies, organisations, or government bodies)
• Sampling (for example, random product sample checks)
• Inspections, in-process monitoring
• Statistical process control
• Issues raised
• End-user testing
• Root cause analysis.

Controlling the quality of deliverables is usually achieved by regular testing (using destructive or non-destructive testing methods), sampling, and auditing. While the most apparent element of quality control might be testing the end-product, it is equally important to perform quality control checks at earlier stages, for example, at various predefined milestones or production phases, in order to have a cost-effective and time-efficient system. These quality processes produce documents that must be maintained as part of the quality control records. Quality control processes ensure product quality by detecting and addressing defects early, minimising variation, and implementing corrective actions to prevent recurrence.

Maintaining quality control records must be observed throughout the project. Audits are a subset of the quality control process and the documentation produced as part of an audit is an integral part of the quality control records that must be maintained. While quality control is usually an internal process with regular quality checks and reviews conducted in-house, audits are more formal and are usually carried out by external auditors.

Quality Control Records and Audit Documentation

Audit documentation is the written record of all audits that are carried out during the life cycle of the project. The audit records are evidence that shows how the auditors reached their conclusions.

According to the Public Company Accounting Oversight Board (2004), ‘Audit documentation includes records of the planning and performance of the work, the procedures performed, evidence obtained, and conclusions reached by the auditor.’

The maintenance of appropriate records and documentation as per organisational policies and procedures, and the project quality control procedures, facilitates quality control and provides an audit trail.

ISO 9000 Part 16 states that:

quality records should give evidence directly or indirectly as to whether or not the product meets specified requirements

Quality Records

Quality records are records kept to demonstrate conformance to specified requirements and the effective operation of the Quality Management System (QMS).

It is important to note that these quality records pertain to records kept as documentation of the quality assurance and control processes.

Quality records can be physical or digital records detailing evidence that the quality management system elements comply with the quality requirements set by the organisation and the ISO if applicable. Quality requirements can include detailed requirements that can be applied to document storage, retention, and destruction.

Audit Documentation

This refers to the documentation or records of audit procedures performed to assure that the project processes and outcomes conform to the quality requirements in place.

Just like quality records, audit documentation can also be in physical or digital format, and these must also be treated according to the organisation’s quality management system.

Maintaining Quality Records and Audit Documentation

Maintaining quality records can include keeping the files up to date, storing them in the proper location, and not allowing changes to already completed records.

Maintaining records also entails ensuring that records are appropriately:

• Identified – knowing which items qualify as quality records, such as lists, forms, charts, and reports
• Collected – knowing what happens to the records, where they can be found, or whom they are passed onto
• Indexed and filed – how records are to be identified, classified, and named
• Stored and made available for easy access – record storage must be secure, whether records are kept in a physical folder, a filing cabinet, or an online database. Security entails keeping the records safe from any damage and granting access to the reports only to authorised individuals. It also implies that people who need access to the records can gain it easily.
• Destroyed – once records have served their purpose and have been stored for the specified time according to the compliance rule applicable to it, they must be destroyed according to organisational policies and procedures. They may be recycled, burnt, or shredded, depending on the nature of the report’s content.

Maintaining the documents will depend on the quality requirements previously identified. It may involve reviewing the completed records and ensuring that they are up to date, checking the timeliness of the information against current organisational guidelines and so on.

The system of recording the results of quality checks should run throughout the project life cycle.

These may include:

• Testing/audit checklists made available to you by manufacturers, industry bodies, organisations, or government bodies.
• Testing/audit checklists developed in-house.
• Product sample checks (for example, one product in every 100 in a production process).
• Reports from external testers/inspectors/auditors from government departments, industry bodies or manufacturers, such as a building inspection by the local council.
• Team meetings where the opportunity to raise issues is listed as an agenda item and issues are reported in an Issue Register.
• Product testing reports from end users.

At every phase of the implementation and controlling phase of the project, the quality management plan must be revisited continuously to assure that the quality requirements are met. From performing quality assurance to maintaining records of the quality processes, all tasks relevant to maintaining project quality must be in compliance with the quality standards and guidelines set in the plan.

Every project needs a project records management system. This system is usually determined by the policies and procedures of the wider organisation and ensures that pertinent records are managed and documented accordingly to reduce and curtail any issues that will arise in the course of the project.

Identifying Records

Records are the documentary proof or evidence that the project achieved what it intended to. Your organisation’s records management system must be able to define what qualifies as record and what does not (i.e. duplicates and rough drafts). While not all project documents can be categorised as records, your records management system must outline how these will be treated. Furthermore, once a document qualifies as a record, its storage and disposal must be compliant of the rules established in the system.

There is likely to be some crossover between the kinds of records that are kept for various purposes, including quality control, quality assurance and compliance. Compliance records commonly include:

• financial records (including tax, transactions, invoices, wages, and superannuation)
• contracts and agreements
• inventory records
• policies and procedures
• ISO standards and checklists
• results and reports of quality reviews, tests, and audits that show standards have been met.

The ISO 9000 Standard discusses what qualifies as a quality record and what qualifies as a mere document.

For example, a newly established set of test procedures is not a quality record, rather a controlled document. It becomes a quality record when it is used to record the steps implemented during a product testing or inspection to assure the product’s compliance with the requirements.

The following are the mandated ISO 9000 quality records:

• Document control
• Management review
• Education, training, skills and experience
• Product realization
• Customer requirements review
• Design and development inputs
• Design and development review
• Design and development verification
• Design and development validation
• Design and development changes
• Supplier evaluations
• Production/service processes
• Identification and traceability
• Damaged/lost customer property
• Calibration
• Internal audit
• Product conformity
• Nonconforming product
• Corrective action
• Preventive action

Any and all quality records pertaining to those listed above must be maintained and controlled. Should there be other quality records that would give an important historical reference for quality activities to respond to critical areas, it is upon the organisation’s management system what other records to consider.

Maintaining Records

Maintaining quality records according to agreed quality requirements also ensures that records are:

• Legible – records must be protected from deterioration to ensure their readability
• Readily identifiable – each record must be uniquely identifiable through a number, title, code, date, storage location, or other appropriate methods.
• Retrievable – each record should be stored and filed in a manner that is easily accessible when the record is necessary.

Records may be stored physically, for example, in a filing cabinet, or electronically, such as in a company intranet or using an online storage system such as Google Docs, Microsoft OneDrive, or SharePoint. When a project uses a project management system such as Jira or Teams, documents may be stored within this system.

Some documentation is ‘baselined’ and does not need to be changed throughout the project (e.g. policies and procedures), while other documents are continuously updated (e.g. financial records and audit checklists).

It is essential to the smooth running of the project that every team member takes personal responsibility for keeping these records filed securely, appropriately, and up to date. Compliance records that can be easily accessed as required allow the project manager to provide evidence of compliance to stakeholders, regulatory authorities, and executive management as needed and provide a clear audit trail.

It is unrealistic and not ideal to expect that any project will run smoothly from start to finish. Regardless of how the team members performed their work perfectly, the project seamlessly complied with the scope, time, and cost requirements, a project is sure to encounter an issue or two along the way.

Problems and issues are inevitable in quality outcomes, specifically the quality of the deliverables and quality of the processes. No matter the severity of the issues, it is important that these are addressed accordingly, for them not to lead to shortfalls.

Identifying Shortfalls and Issues in Quality Outcomes

A shortfall is any discrepancy between the project assumptions, standards set, and the actual project deliverable.

Shortfalls can occur at any phase of a project and in any aspect. For example, a cost shortfall would entail that spending exceeded the budget, or a time shortfall could mean that processes took longer than was scheduled for. In terms of quality, a shortfall could mean that the quality of materials or resources was not on a par with the standards, or that the quality of the deliverables is lacking.

Issues are problems that crop up throughout the project. Some issues are to be expected and easily solved, while others may be ‘showstoppers’ and could potentially lead to shortfalls or even project failure. For example, an issue on the technical aspect could be when a software program experiences a glitch and does not function as expected. The issue could also be of the human resource nature, one where the project team member gets sick and needs to take time off to recuperate.

Issues, no matter their nature, must be identified and dealt with as promptly as possible. This must be observed all throughout the course of the project.

Shortfalls, on the other hand, are unexpected and likely to bear more severe risks on the project. They have the potential to derail the project and will need to be reported immediately to someone with authority to address it.

Shortfalls in quality outcomes can be raised via both formal and informal sources.

Formal sources include:

• recommendations raised in quality audits
• communication from government bodies, industry bodies, or manufacturers regarding a change in required specifications
• change request where the scope, time, cost, or quality is changed
• documented quality testing by internal team testers or end users
• issues raised in contractor reports
• issues raised at a team meeting and recorded in the minutes

Informal sources include:

• issues identified by project team members
• casual correspondence with an end user or stakeholder
• ad hoc issues with contractors or team members
• bad weather (for outdoor projects).

Reporting Shortfalls to Enable Appropriate Response

Depending on your organisational procedures and project methodology, there will usually be processes in place for reporting shortfalls. If you become aware of a shortfall or a potential shortfall in quality outcomes, you should notify your project manager and provide them with as much information as you can so the appropriate report can be done accordingly. Depending on the organisational policies and procedures, there are many ways to report shortfalls.

The two commonly used important methods for reporting shortfalls are:

• Exceptions report
• Issue register

Exceptions Report

An exceptions report, also known as non-compliance report, may be raised to notify key stakeholders of more serious shortfalls in quality outcomes.

The key stakeholders that should usually be notified in the first instance include:

• the project manager
• the project team
• the quality management team
• affected contractors or specialists

Depending on the nature of the issue and how critical it is to project success, the project manager will usually decide if it can be resolved by the project team or if other key stakeholders need to be notified.

These might include:

• higher management within the organisation
• the project sponsor/client

Once the project manager and/or senior management is aware of the issue, they can take further steps to identify the cause and decide on a course of action to resolve the issue or minimise its risks.

Possible actions might include:

• recommend solutions or workarounds to correct the shortfall
• renegotiate outcomes and standards with the client/sponsor
• stop the project temporarily while advice is being sought or a solution is being found
• acceptance of the outcome as is (change to standards)
• rejection of the outcome (failure of the project)

Here is an excerpt from a sample Exception Report template lifted from Prince2™:

Click here to access a copy of a sample Exception Report.

Issue Register

An issue register is an essential tool in the process of reporting issues and/or shortfalls. By documenting all of the issues as they occur, you can keep track of them and promptly resolve them. As the issue register grows, you may start to see patterns emerging. These patterns may highlight that for some recurring issues, there is a root cause that is creating a systemic problem.

Some organisations have their own issues tracking software systems that the project might tap into. This allows anyone involved in the project to populate the issue register, then for project managers to assign the issues electronically for team members to solve. Depending on the size and complexity of the project, a simple spreadsheet or document in a table format may suffice. Each item in the Issue Register might vary in detail from a single line item in a table to a full-page form.

At a minimum, the issue register should include the following:

• an issue numbering system
• the time/date the issue was raised
• a description of the problem
• who raised the issue
• the action history, describing both the process and the solution
• the status of the issue

If the project team is large, the issue register should also include who the issue has been assigned to for resolution.

Below is a sample Issue Register template from Prince2™:

Use the following questions to check your knowledge regarding this topic:

Click on the dots to navigate through the questions.