“Approval authority” sounds like a powerful, “We’re in control” kind of a term. Especially when written into a contract. However, when “approval authority” means signing off on requirements, are you really just relinquishing control and placing blind faith in a software development team?
Despite having signed requirements documents, changes are inevitable. The honest truth is that it’s hard to get software right using only the imagination, which is really all you have with a requirements document.
Have you ever been disappointed by the movie version of a good book? Perhaps the producer’s vision for the characters or the scenery was significantly different from your own? Or worse, they cut out your favorite parts of the story? When you read a book your mind creates the reality, and even though everyone is reading the same book, each person’s reality is different.
In software, a requirements document is like the book and the software is like the movie. In an effort to avoid creating disappointing software, organizations might institute a sign-off process for requirements documents. However, signing any document raises the stakes for the approving group or individual. This is the point of commitment. The point of no return. This is the point when the signers give up control. From this point forward, they may find themselves boxed in, relegated to little more than faith and hope that the development team will get it right. And that their interests will be well-served.
Forcing a “sign off” event in a software development process will slow things down as the “approval authority” sweats the details, making sure all the details are right. The problem with this approach, however, is that people need to see the software to know it’s right. They need to see how it looks and how it behaves before they can gain a real sense confidence in an application. But requirements don’t have that level of detail or granularity. Natural language can do nothing more than describe what something will look like or how something will behave. Requirements documents can never give you that direct experience. So why force business owners to give up control so early in the process?
Agile methodologies address this by encouraging dialog between the business owners and software developers. No sign off is required because the business is approving and denying throughout the software development lifecycle. Preferably these dialogs happen all the time, in an open lab-style setting, with business representatives sitting with the software developers. In this environment requirements can evolve incrementally as the business and technical staff hash through options on how to address the business problems and opportunities use appropriate technology. Assumptions can be vetted, risk can be reduced, and both the business requirements and the technologies are allowed to blend together incrementally until the solution materializes. What is most important is that the business is represented all the way through the software development process. No control or ownership need be relinquished.
Document sign-off, on the other hand, tends to have the reverse effect. As requirements are interpreted by developers, the gap can widen. Fine-grained questions are expensive to resolve using a more formal processes because meetings become the primary vehicle for answering questions. Meetings take time. You have to schedule them, and the more people in a meeting the more expensive they become. So you better have a good reason for gathering everyone together. At least a better reason then whether to place the “OK” button two inches to the left or two inches to the right.
In my experience, document sign-off tends to promote more finger pointing than cooperation: “You built it wrong.” “No, you described it wrong.” While signatures are used as valuable business tools to enforce commitment and provide guarantees, in software they can create unnecessary anxiety and unnecessarily delay the software process. The business owners usually don’t know enough about technology and what is possible in order to make the best choices up front. Likewise, software developers often don’t know enough about the business to make good choices about the intricate details buried within the requirements. So why force the hand-off? Keep the business represented and engaged. During a software effort, developers will have hundreds if not thousands of fine-grained questions. How these questions are answered directly effects the final implementation of the software. Embracing a fluid environment, where conversations can happen dynamically, will shrink the gap between requirements and what is built. Ultimately this will determine the success or disappointment of a software project.
softwareforpeople.wordpress.com 
Hello there, just became aware of your blog through Google, and found that it is really informative. I am gonna watch out for brussels. I will appreciate if you continue this in future. Lots of people will be benefited from your writing. Cheers!