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.
courtesy @TechRepublic
No comments:
Post a Comment