Quality Knowledge Area

Small Projects and Quality Go Hand in Hand (Part Two)

The Project Management Institute’s (PMI) Quality Management Knowledge Area only has three processes, and today I’ll discuss two of them:  Perform Quality Assurance and Control Quality.  (The third process – Plan Quality Management – was addressed in my last post.)  For such an integral topic in Project Management, one is forgiven for thinking PMI shorted this area in terms of attention.  The Time Management Knowledge Area has seven processes, how can Quality only have three?  However – as with many things in life – quantity does not necessarily indicate quality or relative importance.

Planning Process Group

Executing Process Group

Monitoring and Controlling Process Group

Plan Quality Management

Perform Quality Assurance

Control Quality

This article is the latest in a series that examines all 47 PMI Knowledge Area processes in the context of small projects.  Although the framework of processes is tailorable, it may not always be clear what a small project needs to keep versus what may be safely discarded.  In addition, the number of processes can be intimidating; this series provides some ideas about how to bring disciplined project management to efforts of all sizes.

Perform Quality Assurance and Control Quality

The 5th edition of PMI’s Project Management Body of Knowledge describes this process as “auditing the quality requirements and the results from quality control measurements to ensure that appropriate quality standards and operational definitions are used” (p. 241).  Recall from my last post that an output of Plan Quality Management is the Quality Management Plan.  It describes the quality requirements and processes to be employed on the project.  Now it’s time to use that plan to audit the way work is performed on the project.  For example, if the Quality Management Plan stipulates a two-person review process for all written deliverables, then the Quality Group or its representative should audit the project to ensure that yes indeed, two people read each written deliverable before it is shipped to the customer.

So, the Perform Quality Assurance process uses the output of Plan Quality Management.  Somewhat confusingly, it also uses the output of the Control Quality process.  I characterize it this way because the Control Quality process seems to be executed later in the project lifecycle given it appears in the “Monitoring and Controlling Process Group,” – after the Executing Process Group.  However, remember that Process Groups do not necessarily correspond to a particular time period within the project lifecycle.  For example, processes within the Initiating Process Group may be performed when the project is deep in execution to help plan the next project phase.  Therefore, given the close inter-connectedness of the two processes, I’ve decided to address them together in one section.

“Control Quality is the process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes” (PMBOX, p. 247).  Within a software development project, this process refers to those tasks that measure software defects or bugs to ensure the code conforms to the objectives established in the Quality Management Plan.  In essence, it is the measurement and comparison of deliverables against quality requirements.

The Perform Quality Assurance process uses the output of Control Quality to feed into a change process, which can take multiple forms.  For example, let’s say the result of a software quality audit revealed numerous bugs.  Through a root cause analysis, it was determined the new junior developer needed some additional training or perhaps the recently purchased compiler wasn’t as good as advertised.  The change in these cases could be to pay for the new employee to take a course or for the company to purchase a different compiler (and re-examine its product evaluation techniques).

The change process could also take the more formal route of creating Change Requests that authorize a revision to the project’s scope, cost, and/or schedule.  Continuing the example, it could be the company decides to purchase COTs or Commercial Off-the-Shelf software instead of developing code from scratch.

What’s the accommodation for small projects?  That’s already been determined during the first Quality Management process:  Plan Quality Management.  If the project has invested the due diligence to define deliverable quality and how it will be assessed on the project, then the work required for Perform Quality Assurance and Control Quality has already been established.  In essence, a small project tailors Quality Management by what it stipulates in the plan.

Stay tuned for next time when I’ll discuss Risk Management vis-à-vis small projects.  See you then!

Tagged with: , , , , , , ,
Posted in Blog Entry
Ask Eve: Submit Your Question News & events

News & Events

The Risky Business of Small Projects (Part Three)

Risk Knowledge Area

In this space, I have discussed some tools for Risk Management on a

The Risky Business of Small Projects (Part Two)

Risk Knowledge Area

One of the great things about my Project Management course at the University

The Risky Business of Projects

Risk Knowledge Area

I teach Project Management at the University of Arizona, and my graduate students