This is a 9-minute read that describes four quality models, focusing on the inherent quality requirements for projects. This is the second part of a discussion on quality.
In the first part of my discussion (Did you Give up on Quality?), I noted some of the challenges faced by the project manager (PM) in taking a leadership role on quality: a cultural setting not aligned with the prerequisite disciplines; management inattention; definitional confusion; reliance on add-on processes; and a sense of PM disempowerment arising from imposition of corporate initiatives.
The solution, I argued, is to distinguish between product and project quality and to then apply objective thinking based on a new project model. Think of product quality as the aggregation of tangible quality factors possessed by the product, and think of project quality as an intrinsic attribute of a project’s fundamental elements. The intent of this post is to model quality for each of those elements, review some of the techniques and methods provoked by this fresh view, and so put quality back in its rightful place.
Overview of the quality models
The project model developed in part one expanded the classic triple constraint by replacing Scope with the fundamental elements of Objectives, Deliverables, and Activities. A new element, Trade-offs, was added. I am now proposing four quality models that contribute to the completeness and correctness of each of these elements.
These simple quality models have a pleasing arithmetic progression:
- The Point of Quality (the establishment of Objectives)
- The Duality of Quality (balancing the Deliverables)
- The Quality Triangle (the efficiency of Activities)
- The Quality Quadrant (the effectiveness of Trade-offs).
My contention is that projects implementing these four simple models are truly demonstrating project quality and have the best possible chance of delivering a quality product.
The point model
This is the most important because it is the foundation for product quality. The sponsor’s purpose or ‘point of quality’ for the project is uncovered and clearly articulated. This is the closest our new quality model comes to the classic mantra of Customer Satisfaction, but with the critical difference that it is the result of a logical progression rather than a response to a survey.
Customers tend to consider quality primarily in subjective terms, so the PM uses the Point Model to ensure a shift from subjective to objective. Even this is an incomplete transition; objectives are usually only demonstrated when the product is largely finished, by which time it is too late. The model therefore requires a further decomposition of objectives into tangible product quality factors.
A product quality factor is defined as an observable feature of product design that promotes a desired quality objective (conformance to commercial or technical standards, ease of usage, ease of maintenance, adaptability, expandability, durability and etc.). Quality factors that support these objectives are evidence of product quality and may be graded as basic, standard, or superior. This way of thinking not only creates a logical and unambiguous method for documenting quality specifications in the quality plan, but allows for grade to be negotiated, rather than the politically fraught idea of negotiating to reduce quality.
Implementation notes
Although the Point Model is universal, support in terms of checklists for common quality objectives and commonly derived quality factors are dependent on the application. IT and software development in my experience are lacking such support and this would be a useful inclusion in a reference guide.
Techniques are also needed to link subjective expression with derived factors. For example, sessions based on the Socratic Q&A method, bringing technical experts and customer requirements experts together, would proceed using the following high-level question set:
- What are your quality goals for the product? This yields a list of largely subjective needs.
- How will you know if your quality goals are met? This creates a list of quality objectives.
- What product feature would contribute to each of these objectives? This is the end result of the exercise, a list of definable quality factors to be built into the product.
Supplementary questions driving at system life and durability requirements, tangible benefits of quality factors, error-tolerance, maintenance and so forth, should also be prepared. Project time should be allocated for analysis of proposed quality factors.
Other techniques, such as Failure Analysis and Marketplace Analysis, can also contribute. Prioritization techniques will help prepare for potential trade-offs if this need is foreseen.
The duality model
Quality is purposeless without a customer who has specified the need and then works in a transactional role while the need is progressively fulfilled during production of deliverables. The problem is that although customers appreciate the significance of acceptance criteria, I have rarely seen the need for balanced acceptance or approval procedures addressed either in contract or in project documents.
In the Duality Model, the obligations of the supplier are recognized and balanced by the obligations of the acceptor. A good charter (or contract) will explain the protocols for a balanced transaction, especially final product acceptance. The contract will also lay out the terms of the acceptance criteria, if not the specific details. A good development methodology with built-in quality will also apply the Duality Model to interim project deliverables, such as specifications, designs, technical plans, components, subassemblies, and so forth.
Implementation notes
The knowledgeable adherence by both parties to their responsibilities requires agreement to a written procedure. The protocols for this should be based on the following template:
Supplier Protocols: Initiates transaction, Schedules time, Communicates, Declares deficiencies, Meets criteria.
Acceptor Protocols: States criteria, Assesses deficiencies, Adheres to time-lines, Provides feedback, Signs off, Completes transaction.
The Duality Model can be usefully applied to many other transactions and project events. Examples include acknowledgement of messages, information or data, validation of requests received, and protocols governing the provision of materials or resources.
The triangle model
My third model is really at the heart of quality project work. Processes dominate most classic thinking on quality of work and definitely belong in this model, but with much more besides.
The quality triangle is an old but wise illustration of the three fundamentals that create quality work: People,Process, and Technology (PPT). The PM uses the Triangle Model to assess project activities during detailed project planning. Given the people, processes, and technology available to the project, the PM ensures the project activities are optimized for the work to be done. This is reviewed prior to initiation of a project activity and ideally developed in collaboration with the assigned resource.
Implementation notes
Little new development is needed to succeed with the Triangle Model. Activities and practices depend upon the application area – laying bricks differs from writing computer code. The main requirement is for the PM to maintain the discipline of planning, to search for efficiencies, and to engage with the team. Of course, checklists detailed for your organization would be useful, addressing each side of the triangle.
People: Resource assignments require the PM to consider the three main attributes; experience and track record, training requirements, behavioural and personal characteristics. The assessment is much easier if the resource has worked with the team before.
Process: Processes cover the steps followed by the team to develop, verify, validate, and approve deliverables. These are most likely defined by current best practices and the development methodology, which should include QA/QC procedures. Management may require add-ons such as ISO9000, Six Sigma, or Lean, as well as PMBOK or PRINCE2, though the best approach is to properly integrate PM with delivery of the project using methods described in Commercial Project Management. Also consider management processes that may be specified by the performing organization such as: Hiring and on-boarding processes, cost/benefit assessments, development of SORs (Statement of Role), performance management, and essential processes usually embedded in contracts such as change orders, sign-offs, and status reporting.
Technology: On larger projects, technology is often acquired for use by the team, so of course such procurements should be integrated with the project activities and the budgets managed. Ubiquitous social media platforms such as Facebook, Twitter, Slack etc. should be assessed as aids to communication and coordination, as well as technology choices for document creation, modelling, CAD, methodology support, testing, requirements traceability, and so on.
A final note: Corporate quality policy is an ideal candidate to be expressed in PPT terms. Most such policy statements are ineffective because they lack these specifics. An employee should be able to read policy and know how he is affected. The typical “the Company believes Quality is Very Important” doesn’t quite cut it. Quality always flows top-down, so if no such corporate policy exists, the PM (certainly of larger projects) would be advised to construct one specifically for the project
The quadrant model
Any project that takes schedule and budget allocations seriously needs to consider trade-offs designed to reduce work in order to meet the constraint. Unfortunately, trade-off decisions are not always determined logically, and may not be explicit. As a result, the decision may be less effective, and may be regretted.
The Quadrant Model provides a framework for the sponsor and the PM to effectively negotiate changes designed to keep the project work and available resources in balance. Resources are on one axis as cost and schedule, work is represented on the second axis by product functionality and quality factors. The model reminds stakeholders of the connections embedded in a project; a change in one quadrant inevitably causes a change in another.
Implementation notes
Specific trade-off factors can be listed for each quadrant and tabled as input for discussion. If product quality factors were prioritized using the Point Model, this information now comes into play. If factors can be implemented at different grade levels, then retaining the factor at basic grade might be an option.
Other techniques, such as Alternatives Analysis and Contingency Assessment, can also assist with methodical and effective negotiation. The desired outcome is a quality specification that is consistent with schedule and cost constraints.
Finally, remember that down-grading of quality factors, or removal of the less critical functionalities, will almost certainly have an impact on forecast maintenance budgets. Depending on the customer’s budgeting mechanisms, this fact may be drawn into consideration during trade-off talks.
The takeaway
Quality is a tough subject, with a complex history and many dimensions. Today, on most projects, it is viewed as a process issue centred on QC/QA procedures or costly corporate implementations of ISO or Six Sigma. Unfortunately, belief in add-on procedures has redirected PM attention from the essentials of inherent quality work, and corporate initiatives have tended to dilute the PM’s responsibility for quality.
Only rarely do quality initiatives emerge from the bottom up, and corporate leadership has lost its way. So, as project managers, we must reclaim our quality leadership role and change the emphasis on quality. This can be achieved by addressing quality as a matter for project policy, and using quality models for the four project fundamentals:
OBJECTIVES – Understand the specific quality requirements for the product. The Point Model gives the means by which the sponsor, or his quality requirements experts, can properly articulate quality objectives to the PM and to her technical experts for specification. I have signified these as quality factors, and they are critical.
DELIVERABLES – Adopt and perform joint responsibilities for acceptance of deliverables. The Duality Model reminds the stakeholders that delivery of quality is a two-way street, and both supplier and acceptor have responsibilities that must be jointly fulfilled.
ACTIVITIES – Pay attention to the design of efficient activities to be done well. The Triangle Model is a summation of the theoretical foundation for quality of work – People, Process, and Technology. Before activity assignment the PM assesses the attributes of the resource, the applicability of the processes, and the cost/benefit of supportive technology.
TRADE-OFFS – Schedule these discussions as a formal project activity with defined information inputs, protocols to guide negotiation, and agreed outcomes. The Quadrant Model represents the project as a balance of resources against the work needed to build functionality and quality. Use this as a reference to ensure agreements are explicit and logical.
Implementing these models requires customer engagement and the support of the performing organization. A benefit of this approach to quality is zero acquisition expense, and little extra cost. I would argue that it is what the project should be doing regardless. But what do we do if the client shows no interest or understanding? In such a case, nothing will be gained by argument and the best approach is to proceed with the assumption of ‘standard’ grade under the umbrella of a basic QMS. (What is a basic quality management system? A story for another day!)
A Quality Reference Guide expanding the four models could be a valuable project planning resource; what are your thoughts?
