Why Requirements Approval Matters and How To Make It Easier

Getting requirements documents approved can be a pain in the butt. Why do we need to do it in the first place? The approval process is more than just reaching concensus or creating a contract. Done correctly, it presents an opportunity to get more inputs from stakeholders.

The Approval Process

On the surface, the approval process is pretty simple:

1. Write document
2. Review document
3. If changes are required, go to step 1
4. Approve document, reject document, or approve document “with minor changes”

Collaboration And Approval

However, this simple process can become more complex when multiple people must collaborate and approve. Consider the following thumbnail of a real-world approval process:

This process shows what happens with only two approvers / collaborators.

1. Person A reviews the document, and we might make changes.
2. Person B reviews the updated document, and we might make changes, causing us to send the document back to person A.

There are two approaches to dealing with multi-party approvals: do them in parallel, or do them in series. When multiple approvers are reviewing a document with similar criteria, parallel processes work best. When the approvers are interested in different elements of a document, a sequential approach may be more efficient. For example, the business owners will care more about requirement correctness, while the implementation team will care more about requirement completeness. One person has a business context, while the other has an implementation context.

Benefits Of Approval

We do get some serious benefits from eliciting approvals from our stakeholders:

• Course Correction. Feedback that we are headed in the right direction. Maybe our documentation skills need work, maybe the solution / goal / opportunity is a moving target. By getting regular feedback and approval, we can nudge the tiller to keep us on course. This is a key tenet of incremental delivery, where the feedback is based on each iterative release.
• Coverage of Context. We usually have to collect inputs from multiple people to gather complete requirements. These people have different perspectives on the requirements, goals, or processes we are documenting. Getting the multiple inputs, and resolving conflicts of perspective helps. Each interviewee will identify “missing” requirements relative to the other interviewees. Different stakeholders will regularly disagree about requirements. We have to resolve those differences, and getting approvals from the stakeholders will help explicitly manage expectations and document concensus.
• Corporate Closure. Executive oversight is important for large projects. Some execs will get into the weeds and review documents themselves. Usually, they will delegate, such that each of their departments is represented in the approval process

These benefits all help us prevent mistakes and ultimately reduce costs. They can also help a project navigate the murky waters of office politics. “If So And So approved, then this must be worth looking into…”

There are also costs to getting approvals. Primarily, approvals slow things down in the short term (always), and can potentially slow things down in the long term. Most of the time, the benefits outweigh the costs. If the process is painfull enough, the costs will outweigh the benefits.

Process pain comes from delays and inefficiencies introduced into the process. Even with good requirements documents, there are some personalities that make the approval process at best tedius and at worst untenable.

Approver Anti-Patterns

A pattern is a model for doing something in a repeatable way. Object oriented programming brought patterns to the forefront as a way of “standardizing” architectural approaches to solving common problems. Over time, people developed the notion of the anti-pattern – a pattern for doing something the wrong way.

Here is a list of the archetypes of problem-people we’ve seen:

• The Rubber Stamper. Someone who’s approval provides as much value as the effort that went into approving. Sometimes people are too busy, too checked out, or too far removed from the content of the document to be able to provide valuable input. When they stamp their approval without spending the time to truly review the document, they add no value.
• The “I Don’t Get It! I Don’t Get IT” Guy. Remember Big? John Heard played Paul, the rival designer at the toy company. He brings a bunch of emotional baggage into a product design review meeting, and undermines the effectiveness of the group at evaluating the ideas on their merit. Sometimes people are unprepared to review a requirements document. They can quickly absorb a lot of other people’s time as they try and get up to speed. In the mean time, they will do more harm than good by spouting off.
• Johnny Come Lately. Some requirements documents fade and yellow and curl at the edges under a layer of dust before they ever get reviewed. When people pocket veto a document, they hurt the schedule. Sometimes, they do it on purpose.
• The Flip-Flopper. Ever gather requirements, only to have your source go schitzophrenic on you and completely reverse their position when it comes time to formally approve a document? We might record the information incorrectly, when our elicitation techniques fail us. But flip-floppers will fail us even if we capture the information correctly.
• The Pedant. The goal of a requirements document is communication. One challenge in writing those documents is avoiding ambiguity. Editing a document for clarity is good. Wordsmithing a document to make it read precisely the way someone wants can be bad. The pedant will spend time on “that” vs. “which” and “aluminium” vs. “aluminum.” The time spent on these valueless edits can’t be justified.

Making the Approval Process Easier

Here are some suggestions about how to reduce or eliminate the problems that arise from the anti-pattern reviewers:

• The Rubber Stamper. Get this approval off the list. There’s no point in spending time tracking and gaining a meaningless approval.
• The Obnoxious Guy From Big. Also known as the unprepared guy. If folks haven’t reviewed the material on their own in advance of a review meeting, cancel the meeting and reschedule. If the “reviewers” aren’t ready the next time, cancel again. Their behavior corrects pretty rapidly.
• Johnny Come Lately. To quote a manager I worked with – “Pursue, but don’t pester.” Stay on top of people with visits if possible and phone calls if not. The immediacy of your presence combined with the annoyance of being constantly harangued will achieve results.
• The Flip-Flopper. We can usually dampen the oscillations of someone’s revesing opinion with a short one-on-one conversation.
• The Pedant. Helping the pedant understand the context for the document is a great place to start. Then coach the pedant in the fine art of writing requirements, and the need to balance perfection with realistic completion times.

Conclusion

Getting approvals is important. Preventing common approval-problems will make any team more efficient. Hat tip to Kupe for getting us thinking about this one.