Steps 3 and 4. Distribute Review Materials and Have Participants Review Materials Prior to the Session

The most critical success factor for a review is having the participants arrive at the session prepared. This means that each participant has read the material and made notes about his or her questions. Participants who are not prepared will not be useful members of the group. Since people read and review at different rates of speed, it is not productive to have everyone read the document at the beginning of the session. It is also more beneficial if the participants have had time to think about what they read. The subconscious mind can find problems while the conscience mind is engaged in other activities. By reviewing the requirements at least a day before the review session, the participants will be best prepared to contribute to a meaningful discussion.

Point out areas that are critical for each participant to review (when everyone does not need to review the entire document). The author should deliver the requirements document to the participants far enough in advance of the session to give them adequate time for a quality review. Participants are responsible for committing to this work and telling the author when they need more time.

Case in Point

Early in my career, I learned the value of review firsthand. Although these were program reviews, the lessons learned directly apply to requirements reviews. When I was a developer in a manufacturing organization, I was transferred to the group that maintained the parts inventory system. The group had designed and built the system a few years earlier, and it was considered one of the most well-run and successful IT projects in the division. One of the reasons for the success was the emphasis placed on program walkthroughs. Every new program and program change was reviewed by at least two other developers for correct processing, conformance to requirements, standards, ease of readability, maintainability, and error-free logic.

This review philosophy was so deeply embedded in the culture of the group that new employees coming into the group were required to write a program based on a fictional specification and practice conducting a program walkthrough. There were strict rules, enforced by my peer group, not management. A developer was not allowed to test a program before a walkthrough. The program was delivered to the reviewers at least 48 hours before the review session, and they made their individual review a high priority. If a participant was not prepared for the review session, the review session was postponed and the group informally “shamed” the participant who had caused the delay. I was pretty nervous before my first review because this seemed like a tough group. I concentrated on writing a great program and reviewed it carefully myself before handing it out to the group. Everyone teased me the day before the review session, saying “Are you ready?” As we sat down in the conference room and everyone laid my program on the table, I glanced around and saw a lot of red marks, yellow highlights, and notes scribbled in the margins. Everyone’s copy of my program was covered with writing and notes. I gulped as I realized that they were about to tell me all of the things that I had done wrong.

A senior member of the group explained to me that I would be leading the discussion and that this was an opportunity for quality improvements and learning. I was to read the high-level paragraph names (this was a COBOL program) and ask if anyone had comments before moving on to the next paragraph. I took a deep breath as I read the first paragraph name and looked around the room to see who would speak first. A developer I didn’t know well started off by suggesting that I give a more meaningful name to a particular data field. Her tone was calm and objective. There was no judgment in her suggestion. She also noted that she liked the way I had documented the reason for the paragraph. A compliment! I hadn’t expected that, but what I came to learn in that first session, and in subsequent review sessions, was that this group of people was truly focused on quality. The people in the group were dedicated to helping each other produce the highest quality work, learn new techniques, and maintain the outstanding quality of the system that we all supported. I was amazed at what a great working environment these reviews fostered. Developers were constantly asking each other for advice on complex coding strategies and complimenting each other on solving tough challenges. The result of this dedication to quality was that the software rarely had problems. We joked that we were like the Maytag repairman in the TV commercial. We were sitting around waiting for a problem and then argued about who would get to solve it! If I had any complaint about working in this group, it would have been that sometimes I was bored because things went so smoothly! My prior experience had been in a group that supported a system with constant problems. Every morning there were abends (abnormal ends) from the programs that ran the night before, and we spent half of our time fixing critical program problems. This new group was like a utopia—mainly due to the consistent use of quality reviews.