In 1991 David Allen Stokes wrote, “The use of natural language to prescribe complex, dynamic systems has at least three severe problems: ambiguity, inaccuracy and inconsistency.” I have never seen a specification document that did not suffer from at least 2 of the 3 issues related by Mr. Stokes 16 years ago in his article on Requirements Analysis.
If a document is doomed to fail, then why do we continue to attach so much value to such a document?
The easy answer is that without such a document project management and budgeting is considerably harder for managers. Upon further inspection, however, this seems like a poor excuse.
I find specification documents extremely difficult to write and for developers to interpret. Given the choice to accomplish a task it is more likely than not that 5 people would each have a different process to complete the task. If this observation is assumed to be true in most cases then what purpose does writing a specification document serve for developers who must read an interpretation of a client’s wishes.
Specification documentation also is an attempt to predict both user behaviors and future needs for a working web application. A common military adage explains, “no plan survives first contact.” Similarly, no specification document survives the first product demonstration with real users.
Since we cannot predict the future and developers are unable to divine the actual intentions of a client from a specification document why would a company use one to forecast costs? The answer: It is an easy solution for a service provider.
So what is a better solution than the specification document?
Fostering a good working relationship between developers, project managers, and clients enables iterative development on projects.
Iterations are small chunks of projects written quickly to prototype, demonstrate, test, and revise portions of applications. Each iteration should take no longer than 1 to 2 weeks.
So how do you start or estimate time to complete a project? How do you control expectations with clients for the final cost of each project?
The answer is to work with your clients more closely so they understand the cost of doing business this way. Ultimately, the question, “Did your last web application development project go as you expected?” is the most important question. It is hard to believe that any company could honestly respond, “yes.”
Ultimately, productivity in application developments rests with how well a developer understands what a clients wants, how they will use the application, and how quickly the developer can solve complex problems. Iterative development can address 2 of the 3 issues here. The strength of the programmer determines the other.
Iterative development, at a minimum, will develop better relationships with your clients and provide a much better end product in your client’s eyes. The cost for that is immeasurable.
Leave a Reply