by Rick Brenner
When we use spreadsheets to provide support for enterprise-scale decisions, especially financial ones, it's essential to take care that the contents of the spreadsheets are what we hope they are. Reviews and inspections, as adapted from the way they're used in software development, provide a useful means of enhancing spreadsheet quality and reliability.
To address the analogous problem in the software industry, software engineers conduct reviews and inspections, which are now recognized as an effective way to increase quality, enhance reliability, and manage costs. Much has been written about the advantages of reviews and inspections for software development: see the Web site of the Software Engineering Institute for a valuable overview.
Although reviews and inspections aren't universally used, even in the software industry, organizations that do employ reviews and inspections are typically the leaders in quality and innovation.
A review or inspection of a spreadsheet entails a detailed examination of every one of its features — all constants, all macros, all styles and formatting, all formulas — everything. The review is conducted by a small group of no more than eight knowledgeable colleagues. Their task is to identify issues for the creator of the spreadsheet to address.
A good way to describe this process is in a question and answer format. Below are some frequently asked questions about reviews in general, and some additional specifics about reviews for spreadsheets.
An inspection of a work product is a review that takes a more detailed look at the elements of the work product. It may cover less territory, or fewer of the dimensions of the work product. For example, it may cover only the formulas and constants, but not the formatting of a worksheet.
Major issues are a bit trickier. If the review team thinks some issue or issues are important enough, it can require that the product reenter review when the issues are resolved. Alternatively, the team can decide that further review is unnecessary, as long as the issues are resolved.
Thus, the output of a review or inspection is twofold:
Whatever you do, make sure someone other than the author has this responsibility. Most important: the issue resolution monitor should not be affiliated with the team that produced the work product.
Often, management has a conflict of interest relative to participation in a review or inspection. That conflict can arise from responsibility for personal performance reviews, from sponsorship of the product, or from affiliation with those who have such responsibilities.
Even if a manager feels personally capable of resolving these conflicts of interest, the other members of the review team may feel certain inhibitions in the presence of management. Such inhibitions inevitably degrade the quality of the review output. And since it's difficult to determine whether or not team members feel these inhibitions, the presence of management in a review creates an immeasurable risk.
Whenever we add formality and controls to a process, we risk adding bureaucracy. But the risk is minimal for reviews of the kind we're describing. Control of reviews is left in the hands of those executing them. Without management involvement, review issues remain local to the review team. This makes it difficult for the review process to drag out, frustrating the author or the author's team. Even so, since the review team itself could be viewed as an element of bureaucracy, lets examine the "three negatives" of bureaucracy itemized above.
Does the review process add cost without adding value? I think not. The added value is clear — defects are identified early, when they can be fixed at much lower cost than otherwise. Does it slow things down without justification? It does indeed slow things down, but with justification — reduced defect rates. Does it frustrate us? At first, it will seem frustrating, especially to authors. But as we experience its benefits, we come to welcome the reviews, because they save us from the even more frustrating experience of having to correct a design after it's implemented.
As an example of this saved frustration, imagine this scenario. You're a general contractor building a home. You have a choice — you can bring in the city inspector to review the wiring either before you install the wallboard, or after. If the inspector finds a problem after the wallboard is installed, you have to rip out the wallboard to fix the wiring, then reinstall the wallboard. If the inspector finds the problem before you install the wallboard, then you just fix the problem. Now which way would you rather do it?
Those who say "Why bother with the inspector?" might want to consider what happens to your construction business if an undiscovered wiring problem remains and the house bursts into flame two weeks after you turn it over to a customer.
When a spreadsheet is reviewed or inspected, it's compared with a standard of quality. That standard is represented by a checklist of properties that the spreadsheet should have, or should not have. These properties can vary from organization to organization, or even within an organization depending on the work product. I've prepared a sample of desirable and undesirable properties, in the form of a checklist for spreadsheets.
A Tip a Day arrives by email, or by Yahoo! Widget, each business day. It's 20 to 30 words at most, and gives you a new perspective on the hassles and rewards of work life. Most tips also contain links to related articles. Free!