Agile Project Management Process Grid–Process 5.3 Define Quality Standards

The Agile Project Management Processes Grid has been created by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference.”   He divides the 87 processes used in agile project management into five process groups and seven knowledge areas.

This post covers the third of three processes in the block of processes that are used in the Initiate process group and the Risk Management knowledge area:  Quality Standards.

The first two areas of risk analysis dealt with

–organizational practices, those risks which are inherent in the organization, on the one hand, plus those risk that are inherent to the specific project at hand, and

–regulatory discovery, meaning the analysis of governmental regulations that have a potential impact on the project

This third area is covered by this process, and this is to Define Quality Standards.

Definition of Quality

Some terms used in project management have a different definition that those terms do in everyday conversation.   Quality is a term loosely applied to a set of characteristics that show a degree of excellence, but in the project management sense of the term, quality is the set of characteristics that correspond to the customer’s needs and expectations, in other words, the customer’s requirements.

For example, if I am shopping for a new car, in the everyday definition of the term quality, an Audi might be considered a higher quality car than a Volkswagen because it is “classier” looking or it has more expensive materials in the passenger compartment.   But if I do research and the particular model of Audi I am looking at has a higher defect rate than the Volkswagen as measured by J.D. Powers customer surveys, then the Volkswagen will have the higher quality because there is less chance of my needing to take it in for repairs.

In any case, because agile is so focused on interaction with the customer, quality seems like a natural constraint to focus on in a project.

Need for Quality Standards

However, one of the characteristics of an agile versus a traditional project when it comes to constraints is the notion of the fixed constraint.   Although scope, time and cost are thought of traditionally as the “iron triangle” of constraints, it may be a more instructive image to think of them as a triangle-shaped water balloon.    If you fix one of the ends in your hand, the liquid is free to flow between the other two ends.   In a traditional project, the scope is usually the “fixed” constraint that is determined as completely as possible in the beginning of the project.

In an agile project, however, the time or cost may be the fixed constraint, which means the scope may need to be adjusted.    Here’s how this affects quality:   if you are under pressure to get a project in on time or within a certain budget, then there is pressure to perhaps reduce the scope, or amount of features that go into a product.   But if you reduce the features too much, so that the resulting product does NOT meet the customer’s needs, then the project will be a failure even if it is technically a success with regards to the time or cost constraint.

This is why quality standards need to be defined.

Quality-In Design

Not only do quality standards need to be defined, but they need to be defined EARLY in the project, before detailed planning starts to occur.  That’s why this process is in the Initiate process group, by the way.

The reason for this is the simple empirical law that the cost to fix a defect rises exponentially the later it is discovered.  Rather than spending the enormous amount of time and money needed to inspect and repair defects either before they leave the factory, or, even worse, after the product is in the hands of the customer, it is best make an early investment in designing and developing a product so that the defects don’t occur in the first place.

Here following best practice standards and guidelines should be the focus of the agile team so that the iteration review meetings show explicit progress towards key stakeholder goals, which should be defined in a clear way.    This helps prevent cutting corners when faced with limits on time and budget that might have an adverse impact on the quality of the product.    That is how to reduce risk when it comes to the quality constraint on an agile project.

The next series of posts are on the sixth knowledge area of Communication and the two processes from that area that are done in the Initiate process group, Process 6.1 Colocated/Distributed and Process 6.2 Participatory Decision Making.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: