Design Documents - The Practice of Cloud System Administration - page 279

Different kinds of documents may need different approval workflows. Informational docu-
ments may have a very lightweight or no approval process. More extensive approval may
be required depending on the scope or impact of the document. Your approval workflow is
likely to be determined by your change control or compliance requirements.
13.5.1 Reviewers and Approvers
A design document usually lists authors, reviewers, and approvers. The authors are the
people who contributed to the document. Reviewers are the people whose feedback is re-
quested. Approvers are the people whose approval is required to move forward.
Reviewers typically include team members who might end up doing the actual work of
the project. They can also include subject-matter experts and anyone whose opinion the
author wants to seek. Adding someone as a reviewer is a good way to “FYI” someone in
another group that might be impacted by the project work. You should expect meaningful
commentsfromareviewer,includingpossiblycommentsthatrequireyoutomakechanges
to the document.
Approvers typically include internal customers who are dependent on the results of the
project as well as managers who need to sign off on the resources used for the project.
Sometimes approvers include other audit and control processes mandated by the com-
pany—for example, a privacy assessment or review of PII used in the project. People who
conduct audits of compliance with regulations such as SOX, HIPAA, or PCI are also ap-
provers in the design document process. Approvers are generally a yes-or-no voice, with
commentary usually accompanying only a “no” decision. It will be up to your individual
process to determine whether approvals must be unanimous, or whether one or more neg-
ative approvals can be overridden by a majority of positive approvals.
13.5.2 Achieving Sign-off
The reason to make a distinction between reviewers and approvers is that approvers can
block a project. Trying to get consensus from everyone will prevent any progress, espe-
ciallyifoneasksforapprovalfrompeoplewhoarenotdirectlyaffectedbythesuccessofa
project. People on the perimeter of a project should not be able to block it. Everyone has a
voice, but not everyone has a vote. The reviewer/approver distinction clarifies everyone's
role.