What is a functional specification? A functional website specification provides in detail what a piece of software or a website will do. It is a clear list and description of all the functions that will be built and tested by a service provider and what the client agrees will be achieved by the end of their project.
When should a website specification be provided? If a piece of work is significant, in that it will last longer than 1-2 weeks or requires multiple back end developers, then it requires a specification in some way, shape or form.
Sometimes the specification isn’t even client facing but is an internal process that allows the developer to think through the full requirements from start to finish and identify any issues prior to the work being started.
There are 3 very good reasons to write functional specifications and only one potential negative (which is a fallacy). Below I’ll highlight the advantages of providing a clear and concise specification and why it protects both parties involved in a project.
It is worth starting by addressing the common negative that is always touted; that writing a functional specification wastes time when a programmer could be actually developing work.
While writing a solid and useful functional specification does take time, in my experience this has always been time, and money, saved by the end of the project. I see not writing a clear specification as the single largest risk that could be avoided in creating a successful project. Producing work without clear guidance on what is required and expected leads to unproductive developers who tend to write poorer code than they would otherwise be able to produce.
3 Excellent reasons to write a functional specification:
1. It saves time with internal and external communication. All people work from the same signed off document. The developers write code to achieve the objectives, the project manager or test team QA (Quality assure) against the defined functionality, the business development and sales team have a document of what the company has built for other clients and most importantly the client has it so they know exactly what they paid for and are receiving prior to it being built.
2. It allows you to schedule and estimate time appropriately. Having a clear list of functions required allows the developer to estimate the time required to meet those objectives, thereby allow the project manager to work to realistic timelines. They can then use this to organise their testing teams and set the client’s expectation. The client now knows when they will have environments to add products, copy etc. It also includes what they need to collect at the outset of the project. This always saves time at the end of a build as the client has been able to set internal timelines to collate copy and content and task people within their organisation with the creation of what is always a considerable amount of work.
3. It protects both parties in the event of changes in personal or requirements. We see this all the time when a project is started and the work is agreed verbally or with a loose scope of work. Someone changes their mind or a new person comes in and has different ideas and the work requires changing – not a problem that’s why we have change requests! Without documenting the initial requirements and the changes we often get a situation where the words; “we thought it would…” are spoken. The specification avoids this horrible situation whereby the expectation is that either the agency does additional work for free to please the client or the customer has to pay more for work they now require and feel should have been included at the start. All these are avoidable situations if the work is explored in its entirety. There are no surprises and everyone can be delighted in the end product.
Hopefully, this provides a few good reasons to make sure your agency is taking your project seriously. If you have any questions give us a call or email email@example.com