Section 5.6. Use Inspections to Manage Commitments

5.6. Use Inspections to Manage Commitments

A successful project needs more than just a blanket agreement between team members. It's very easy for someone to "agree" to a document, only to turn around later and decide that he didn't fully understand what he was agreeing to. Instead, the project team needs to reach a true consensus, where each person fully supports the document. The goal of an inspection is to build consensus on the document by gaining a real commitment from everyone who has read it. When a reviewer approves a document, he takes responsibility for its contents, and if the document has defects, he shares some of the blame for missing the mistake.

The best way to reach consensus among the inspection team is for each person to feel like he or she made a real contribution to the document. The inspection meeting accomplishes that by allowing each person to find problems in the document and help the rest of the team find a solution to each problem. This is why it's important for the team to go beyond just pointing out the defects in the document and actually come up with replacement wordings that fix the defects.

By the end of the meeting, nobody remembers that one person suggested this sentence, and another suggested that one; everyone feels a sense of ownership because it was a real group effort. That ownership means that each team member leaves the meeting with a real commitment to the document. This can eliminate many of the conflicts that can cause problems later on in the project.

Inspections are also important for gaining real, meaningful approval for a document. When a document is not correct, that puts the team members in a very difficult situation. Consider a stakeholder who is reading a vision and scope document, and who has a problem with some of the contents. She can't just refuse to approve the document; that would mean that she was personally holding up the project. But if she lets the document move forward as is, that could cause serious problems later in the project. So the stakeholder feels backed into a corner. She can't approve the document as it stands, but she doesn't have the authority to make changes to it. Typically, people who are put in this situation simply avoid reading the document, giving them a sort of "plausible deniability" that lets them avoid blame when the project has problems later.

Inspections are a way out of this situation. The inspection team is given the responsibility of approving the document. To accomplish that, each member is given the authority to withhold approval until any text in the document that prevents them from approving it has either been changed to meet their needs or has been explained to the approver's satisfaction. This allows the project to move forward.

Other kinds of reviews are also useful in managing commitments. Deskchecks are especially important for gathering consensus among people in the organization who do not need to approve specific documents, but whose input is still very important.

Project teams are made up of people who all share a common goal: getting the software project out the door. Stakeholders, users, engineers, and project managers all have this goal in common. This means that each person should be willing to take on responsibility to make sure that every document produced over the course of the software project is correct.