You cannot inspect quality into a document!

Inspections are a failed analogy.SEI writes in the page about software inspection:

Software inspections provide value in improving reliability, availability, and maintainability.

They don't mention however that inspections improve reliability, availability and maintainability of the inspected artifact. In most software companies the inspected artifacts are: documents. This means that instead of improving the software itself (what the customer pays for), many companies spend large amounts of money inspecting documents that add no value to the customer.

It could be argued that inspection of documents reduces errors in software, however history proves that that is not so. The Chaos report talks about all kinds of projects, and they include projects that have inspections!

You cannot inspect quality in, you have to build quality in, and inspections do not help you with that.

You cannot inspect quality in

Documents are written by people. Even if people follow a process thoroughly when writing documents, the actual writing process is a creative process. Creative processes are not good candidates to be in "statistical control". Only processes that are in statistical
control can be improved by inspection and continuous improvement.

What does this mean? You must be asking. Well, it means that since writing a document is always a unique process (not repeatable) trying to inspect problems out of them will not yield any lasting results.

Consider this: even if you were to remove all defects from one document, the next document from the same person would still have defects. What did you gain from the inspection process? Nothing. You may have removed some defects (there's not even a way to tell if you removed the most important ones!) but you did nothing to improve the way you work! You are back to square 1 every time you write a document.

You cannot inspect code or ideas in a document the same way you inspect the size of some car part fits the appropriate measures. This is basic process quality.

Documents are not parts in a car

Documents are not written to specifications like parts in a car are built. There's no specification for documents (maybe a templates for documents, but not specifications). Documents are a result of creative effort and not considering this is a primary failure of software inspections. Software inspections try to find mistakes after the fact when what we should be doing is preventing mistakes from happening in the first place.

Don't despair yet, there's hope.

You can improve your software development process and save time at the same time. Instead of trying to find errors after writing the document you should build your process so that errors don't get in to the document in the first place.

A friend of mine did just that when he switched the review process on it's head and instead of planning the review after the document is written he started planning the review of the document before the document was written, this allowed for the stake holders of that document to talk about it's content and finally settle on a common understanding of the problem before the document was even started. That common understanding was then crystallized into the actual document. In this process the document is only storage for a common memory, it can be used for future reference when in doubt, but the real communication happened way before the document was written.

In this document-writing process the review process became a communication catalyst, that's the real value in a document, communication! Trying to find defects after the fact is a waste of time and effectively avoids effective communication.

If you want to institute reviews or inspections in your company consider doing them before you write the document, not after...