What is a project specification? It is a document that defines exactly (note the word exactly) the requirements developing a system, from beginning to the end of a project. Project specification is used in almost all web and mobile development processes. Normally, it is a very long exhaustive document for clients to read. Its purpose is to ensure that all stakeholders such as end-users, clients, developers or designers know exactly what to do for the project and acts as a binding document between the client and the developer to deliver on the features stated in the document. A project specification can also be evolved to include functional specification, design specification, user acceptance testing, etc. Nevertheless, it is a “complete” documentation to capture all requirements of the project.
So what’s wrong with using a project specification? Shouldn’t we write out clearly first what we do before we do it? Is that all part of diligent planning? What is the problem with this document method that has been used for so many years?
There is no problem in due diligent planning. In fact, we should all do it. Planning ahead enables us to anticipate problems before it comes up so that we can reach our goal on target and on time. However, let’s ask ourselves very truthfully: when is the last time everything goes according to plan?
Changes, Changes, Changes!
When you are dealing with a complex system, you are inevitably creating new ways for end-users to use the system. At the beginning of the project, you seek to write down everything into a project specification document. You are actually trying to guess best way to build this system and for end-user to use the system. The more complex the system, the more guesses and assumptions you are making. Now, make a guess how likely everything is going to turn out exactly as you planned. If you are lucky or if the project is a simple one, you would probably get it all correct. However, most of the complex projects we have developed turned out at least 30% to 70% different from what we originally conceived with the clients. If we had bound our project specification with our clients on every complex project, the end-result would not be a satisfactory product or even worse, an un-usable system for the end-users.
“Hey, maybe you guys are just not experienced enough to handle it.” Ok I heard the question and here’s my humble answer: maybe we are not experienced enough. And here is what my own experience tells me: project specification works for simple projects but not for complex projects. There are very little variables to a simple project such as a simple corporate website or a pretty straightforward shopping cart system. However, faced with a complex projects such as creating a new backend system for large corporate employees to use, a project specification rarely fits the bill. We have spent countless hours with the client to nail down all the requirements but only to be changed later due to operation constraints, as a result of newly discovered requirements or even worse, differing political agendas between departments. End of the day, the more we assume we know everything exactly in the beginning, the more we are proven wrong by the project in the end.
I can’t help but feel that a project specification is analogous to a business plan. A business plan seeks to nail down all the requirements to start and operate a new business to profitability. However, market forces eventually create changes in the business plan. Inevitably, one has to adapt the changes into the plan in order to continue moving forward. Imagine the owner of the business plan refuses to change any part of his plan and stubbornly moves on. How likely is that going to bring success to the business? In the same context, how likely will a system be useful if we always stick to the project specification document in the beginning? You decide for yourself.
The Ugly Truth of Project Specifications Most clients feel at ease when a project specification is created and written down to the last detail of what they want. They think that the developer will now have to fulfil and give them exactly what they want without any excuse to fail. However, this is the false illusion web developers love to create in clients.
The real truth is that the project specification is a binding document in which web developers present, to prevent client from changing the requirements or adding more scope to the project. Changes in a project inevitably leads to more development hours and hence, more cost for the developers. Developers need to control the client from making too many changes (something known as scope creep). In the beginning of the project, everyone knows the least about the project so the amount of requirements needed are the least. If the client did not say they need this requirement in the beginning and it is not captured in the project specification document, it is considered out of the agreed scope of project when the client makes a request to change later. By binding the client down to the written requirements, developers ensure that they limit their development hours to the project and hence, make a profit out of it.
There is absolutely nothing wrong with web developers making a profit out of client. If we don’t, how can we feed our family? However, as a web developer, our end goal is also to ensure client gets a product they want through our services. Using a project specification limits this customer satisfaction greatly. Generally it leads client and developers into a contract renegotiation at the end. When it comes to contract renegotiation, e.g. “this statement in the project specification means this, not what you interpret as that”, no one wins and no one will leave the table happily. We need a better solution.
Agile Manifesto
In my humble opinion, one of the greatest breakthroughs in web development methodology is the agile process. Its principles are stated very clearly in http://agilemanifesto.org/. One of the agile principles is “Responding to change over following a plan”. So how can we respond to changes? Planning is still very important and it cannot be eliminated. We still do a project specification document for our client but we have changed the form of it into a card-like system using http://pivotaltracker.com/. In this card-like form, changes can be made easily while maintaining a clear overview on all the requirements. We don’t bind our clients to the project specification or requirements. Client suggests improvements or changes to the system. Heck, we even suggest changes to the client (more often than the client themselves!) so as to build an even better product. We moved from contract negotiation to collaboration with the client (which is also one of the principles of agile process). End of the day, our client gets what they want and we are happy with our work (and the paychecks of course).
There is inherently nothing wrong with writing a project specification document. The error comes in when we assume that it will not be changed and everything will be developed accordingly without fail. The assumption that we know everything even before we develop the product will eventually be corrected by end-users or the market itself. A development contract should not be binding to a project specification but rather to the end goal itself. Client should be prepared for changes and seek flexibility in the contract and development methodology with the developer in order to produce a great final product together.
Agile development process understands the changing nature of the software projects and seeks to accommodate it rather than locking it in a project specification. It encourages more collaboration over contract or requirements negotiation and responding to changes over following an outdated project specification plan. End result is a better product and greater customer satisfaction.
So the next time you start writing the requirements of your project, remember that you are just guessing how it should be and whatever you wrote, would be subjected to changes later on.
