Gathering requirements is a fun job. But once they are gathered and documented, we have to get them approved before anyone can use them. Approval is important. We can do it the easy way or we can do it the hard way.
Two dimensions
There are two dimensions that we can control when getting approval for the requirements in a given project. The first dimension is controlling how much we want to approve in a single session. The second is controlling how many people are involved in each approval session. Think of these two dimensions as quantity and democracy.
Quantity
Many projects will create a monolithic requirements document, for example, an SRS that represents the specification for an entire solution. This document will / may / should be subdivided into different areas. We might break down an SRS into the sets of requirements that support different goals. We might organize requirements based upon the affected areas of our customer’s business. We might organize them by release.
Many projects will also involve business process modeling, and we can either lump all of the modeled processes together, organize them into groups of related (or interdependent) processes, or treat each process individually.
We can control the quantity of requirements/processes/documentation we approve in any given session.
Democracy
There can be several stakeholders for a given project or even a given requirement or process. There are usually many people who are involved in a process, or who would benefit from improving it. And those people can be represented by someone with authority (a manager, a project sponsor, a company visionary). Enterprise software often involves and benefits people from multiple organizations – each of whom may appoint a representative for the purpose of getting approvals.
There are also stakeholders on the implementation side of a software solution – development, testing, and training organizations come to mind. Again, each group will have multiple involved people, and may elect a single representative.
We can control the democracy of an approval session by controlling how many people are invited to any given session.
The Levers
The more content we try and review in a single session, the more painful that session can be. Each evaluation should involve critical thinking and concentration. We gather business owners to validate correctness of a requirement (or process document). We gather implementation team members to validate completeness of a requirement.
Limit an approval session to the amount of documentation that can be reviewed in one to two hours. Less than an hour makes it difficult to “create” the context required to make insightful decisions about correctness. More than two hours will glaze the eyes of participants, and gaps and errors are more likely to slip through.
Shorter sessions lead to less pain.
As we increase the number of people invited to an approval session, we risk crossing the event horizon of the design by committee singularity. Eventually so many agendas are collected in one conference room that no good ideas can escape. Time itself is slowed by the density of the participants.
When possible, identify a single business owner with authority and responsibility for each grouping of requirements / processes that need to be evaluated. Many organizations will make this impossible, as they are still experimenting with the matrix and cross-functional reporting structures. Limit a session to three authorities when a clear owner can not be identified. Have multiple sessions if you must.
Fewer people per session leads to less pain.
Dogfooding
We are currently supporting the first phase of a multi-year project, documenting as-is business processes. We have organized our processes into about a dozen functional areas, segmented by business objective. We have a few dozen processes that we have identified as being affected in the current phase of the current project.
Today I facilitated identification of a single business owner who approves each individual process. And we agreed to approve each process individually. That’s a lot of meetings and approvals, but we have about half a dozen business owners and as many business analysts, so it will be manageable. The main risk to this approach is that we overlook the “touch points” between processes. We will also work to validate the big picture, so that we properly validate our representation of the connections between the processes. We may review multiple processes per meeting, but we will strictly adhere to our timeboxing of two hours per session.
We are also only doing business signoffs after the following are true for each process:
- Subject matter experts and the authoring business analysis agree that the documentation is correct.
- Peer review by other BAs on the team has reviewed for style, quality and consistency of documentation.
- The technical / implementation lead for the project has reviewed the documentation for “implementability” by checking for ambiguity, verifiability, attainability, and sufficient level of detail.
Conclusion
When going through the approval process for validating requirements and process documentation, we want to minimize the pain and maximize the benefits of approval sessions. Manage meetings to last between one and two hours, with no more than three approvers (one if possible). Adding time or people reduces the quality of the feedback.
