Specifications – you need them for web project as well

My blog post is inspired by a meeting where I had a role of mediator between web developing company and customer. The issues were quite simple and common: increasing costs due to neglected specifications and some badly described features.

Customer and web development company are in the same boat, although this fact is often forgotten once it is time to show the work and pay the money. The typical problem is lack of signed specifications. There are several reasons why specifications were not prepared:

1. “The project is too simple for specifications” FALSE – there is no project too simple for specifications
2. “The project is too complex to specify it in one go” FALSE – There should be specifications made for separate parts of the project and compiled into whole document.
3. “xxx development model does not requires specifications because it is superior” FALSE. I hear this quite often from “fans” of Agile-alike development model. Although the whole spec is not prepared, you have to write down what are you making right now.
4. “The customer will not understand the specification” YOUR PROBLEM – customers are not dumb. As long as you use human language, they will understand you. The goal of specification is to explain for both sides what to build and what to expect
5. “They haven’t asked for one!” They need one, though. And in fact, you need a specification too. I have seen customers using awkward terminology that can be very confusing for people outside their company. The web project specification helps in cases client refuses to pay because they expected something else.

Typically, lack of specifications is assisted by pay-per-hour payment model. This is quite useful short term for the company which wants to make money from the customer, but is quite bad long-term strategy. Specification saves time used for redoing project, which leads to customer frustration. And frustrated customer is not a customer that is happy to pay and hire you again.

Furthermore, good explanation of things between client and developer saves lots of time that would be used to develop too complex and completely useless things. During the discussion I mentioned above customer had to explain to developer lead that all they needed for particular attribute was a simple manual checkbox instead of complex automated state machine (and couple other problems). That would not have happened if they took care to update a specification.