Leadership

Project management: Pin down how your client defines quality


A good definition of quality management is "to first understand the expectations of your customer in terms of quality and then put a proactive plan in place to meet that level of quality." The first part of this definition can be the toughest - understanding what quality means to your customer.

Your customer may only tell you that you should build a "good quality solution" or you should build a solution with an "acceptable level of quality." Your response to that should be "Great. But what the heck does that mean?"

The customer needs to state that the project solution needs to be:

  • Reliable
  • Easy to use
  • Easy to maintain when completed
  • Available when needed
  • Flexible for future needs
  • Intuitive / easy to understand
  • Secure
  • Minimally defective (Doesn't have to be perfect)

Once you've gotten that far, you need to help the customer drill down further. Let's say that the customer thinks that a good quality solution needs to be "secure." Further probing might reveal that for the customer, this means

  • The solution should be place in a secure room with password access
  • Only authorized people can login
  • The password must change every thirty days
  • There will be role-based security so people can only see data that is consistent with their roles.

People sometimes ask where this information gets documented. It's easy - these end up being detailed quality requirements and they're captured along with all of the other project requirements.

Most project teams don't make it a point to capture all of their quality requirements. Most project teams focus requirements on understanding features and functions. If you focus on features and functions, many of the quality requirements may come out as well - usually by accident. But if your team is trying to practice formal quality management, you should have a discussion with your clients that focuses on the broader and more specific set of quality requirements.

8 comments
mikifin
mikifin

This doesn't even cover an introduction to the topic. It would be nice if more substance was contained in your "stuff."

sergio.tarzia
sergio.tarzia

Very good points are raised here - this is in fact what sometimes is termed as "Non-functional requirements". There are frameworks which aid the gathering of such requirements in a concise, risk based, and testable manner. It is also clear that to some individuals out there, this sound simple and obvious. I have personally seen both projects (and organisations at large) fail at delivering quality because of not asking "the stupid questions". It was far too obvious... sure thing. And another bundle of millions are thrown down the drain. As consulting professionals, it is the stupid questions that most times I've seen add value and ensure success. If you ask a person how to tie your shoe laces, you're most certainly going to get multiple differing answers. And there'll always be the one who uses Velcro and will not know how to write the requirements at all - hence fail at the assignment.

vijayk29
vijayk29

A good article which can serve as a starting point to capture quality requirements as a part of the project requirements. This at least gives you some pointers to ask the customer and make him/her think more of what his quality requirements are.

richard.ots
richard.ots

Can we next get an article on how to tie your shoelaces?

crittermn
crittermn

As I read the article I had similar thoughts. But as I thought of each of the points made, each could be a book, AND, there are other quality points that can be made. This blog is a good reminder to include quality requirements in project requirements. It makes that point. It is up to others to implement this 'mini-checklist'. The only thing I would add is a reminder to also include quality metrics -- not just glittering words. I've also seen projects waste big bucks when quality wasn't defined in exact terms.

william.burgesen
william.burgesen

First grasp both laces - one in each hand Then put the right one under the left one - errr I mean the left one over the right one and then ummm -- I actually have velcro straps on mine - much easier!

sergio.tarzia
sergio.tarzia

Very good points are raised in the article - this is in fact what sometimes is termed as "Non-functional requirements". There are frameworks which aid the gathering of such requirements in a concise, risk based, and testable manner. It is also clear that to some individuals out there, this sounds simple and obvious. I have personally seen both projects (and organisations at large) fail at delivering quality because of not asking "the stupid questions". It was far too obvious... sure thing. And another bundle of millions are thrown down the drain. As consulting professionals, it is the stupid questions that most times I've seen add value and ensure success. If you ask a person how to tie your shoe laces, you're most certainly going to get multiple differing answers. And there'll always be the one who uses Velcro and will not know how to write the requirements at all - hence fail at the assignment.

richard.ots
richard.ots

... just don't assume too much. The reason why I am not impressed with the quality of the article is not because I don't think that the questions should be asked. It's rather that I'm surprised that this would still be new to anyone. Regardless of whether or not people manage quality and expectations in the way described in the article, I'm quite convinced that everybody at least is aware of the need. Hence the analogy with tying shoelaces. I agree that it's necessary to tie your shoelaces, but I don't need anyone to tell me how to do it. Even _if_ (if!) maybe every now and then my laces aren't tied the way they should be. So, for anyone who doesn't know how to tie his / her shoelaces, I think this would be a good article. However, if that's TechRepublic's intended audience, then I'll start looking elsewhere for my information.

Editor's Picks