Improve project efficiency and effectiveness by dealing with quality part 2

OK, so once you have defined the quality activities required for each deliverable, you are now in a position to start identifying quality requirements for the deliverables – hardware, software, documents, scripts.

This is where many projects really fall down – of those that made it this far 😉

I’ve written about ISO9126 before, but it’s important to start off with just the basics and build a foundation.  This includes both customer and staff expectations.

It’s really an education process – making sure everyone has a common understanding of the quality activities and how to define and use quality requirements.

ISO9126 defines many potential attributes and when projects try to use it they often attempt to use all of them (the ‘ilities’).

But defining them all without having the process and quality infrastructure in place, you end up with:

a)      a mess that no one understands

b)      a complex specification that no one understands or cares about

c)      a mess that causes chaos during scoping, testing and more

So instead, just define a few quality requirements for your most critical deliverables.


Software – reporting module                 0 level 1 defects, <15 level 2 defects

Document – specification                      0 level 1 defects, < 20 level 2 defects

But you might say “whoa! Defects remaining in the specification? Are you crazy?!”

Well, no.  In many projects we may not have time to get all known defects corrected – particularly if they’re not vital to the functioning of the product.

Once you have defined these basic defect measures, check with the team, the sponsor, customers and any other stakeholders.  Remember it’s an education process and people are often not used to this.

Once you have defined and agreed the defect levels, ensure that you have the activities and the checks built into the schedule.  No use having defect levels but no tasks or time to manage them.

By the way, remember to define what defect levels mean – a level 2 might be different between a document, script and source code.  Don’t get hung up on severity versus criticality – this is a semantic argument and doesn’t add value to your project.  Just make sure you are consistent in your use.

If you define defect levels as quality requirements, you’ll find a better understanding and gain more visibility into what customers actually want.

We’ll cover more sophisticated quality requirements (e.g. maintainability, understandability) next time.

PS these quality requirements/attributes are often called “non-functional” requirements.

This entry was posted in agile, alignment, CMMI, defects, Effectiveness & Efficiency, improvement, ISO9001, ISO9126, KPI, metrics, peer reviews, PMO, problems, process improvement, product quality, productivity, quality, software quality, structure and tagged , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

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 )

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s