Process and Product Quality Assurance

Watch what you’re doing

The CMMI Handbook says:

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

If you read what they have to say, it is very much geared towards larger organisations. But clearly, quality is something all customers have a right to expect, regardless of their contractor’s size.

So how does one “assure” quality?

They go on to explain that the steps to do that are:

Requirements Management

Requirements Management

CMMI has this to say:

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

I don’t know about you, but this sentence leaves me confused.

Which is really unfortunate, because requirements are very important, and at the same time many people neglect them.

This topic is so broad it deserves its own series (which I will write in time), so let’s just give a 10000ft view here.

configuration management

Configuration Management

Do you know all the data your project consists of? And where is this data?

What exactly did you even send your customer in last week’s demo?

Controlling your versions and baselining your work products will be a tremendous help if your customer inevitably changes their mind. You don’t need to be afraid of change: it’s to be expected that your customer’s ideas evolve as you build their product for them. But only if you know with certainty what was agreed and what was delivered, and when, you are well equipped to talk to them about the consequences of change. Be they related to scope, cost, time, or anything else.

Konfigurationsmanagement

Konfigurationsmanagement

Kennen Sie alle Daten, aus denen sich Ihr Projekt zusammensetzt? Und wo sind diese Daten?

Was genau war eigentlich in der Demo enthalten, die Sie Ihrem Kunden vergangene Woche geschickt haben?

Versionskontrolle und Baselines sind eine große Hilfe wenn Ihre Kunden unweigerlich mal wieder ihre Meinung ändern. Veränderungen sind ja gar nichts schlimmes: es ist vollkommen normal, daß sich die Ideen Ihrer Kunden weiterentwickeln. Aber nur wenn völlig klar ist, was vereinbart war und was geliefert wurde, besteht eine gute Basis, um über Veränderungen und ihre Konsequenzen zu sprechen. Wie auch immer die Konsequenzen geartet sein mögen: Zeit, Kosten, Umfang, oder alles andere.

Project Monitoring and Control

Do you know if your project is doing well?

I mean, really. How can you tell?

Because your customer hasn’t shouted at you yet? Clearly, that’s an unsatisfactory way to find out. So how can we do better?

CMMI claims:

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

Read more

Supplier Agreement Management

Suppiler Agreement Management

The CMMI handbook says:

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products and services from suppliers.

I think finally we’ve arrived at a topic that is of little relevance to small companies. Not because they don’t buy stuff from suppliers, but because the volume will often be low enough that it can be dealt with without a formal process.

The notable exception may be if you buy items to directly or indirectly sell them on to customers, at a larger scale. But at that point what you are doing stops being engineering, and starts being trading. And that has its own customs and rules.