It’s just another day at work and as I sat on my system to look at the mails, basically the leads I have been assigned for the day. My heart sank to see those one-liner queries, put plainly in the form of a requisition of an app similar to one of its famous counterpart. For instance, this one said, “I want to build a sports social media app.”
Now for the prospect this is the simplest way to put across his requirement; but for someone like me or a member of the technical team, this is a distressing situation. It’s like asking a chef to prepare a five course meal similar to that of a renowned eatery, without giving him a hint about the preferences of the guests.
So, what do I do?
Start preparing a feature list all by myself or at times with the aid of a member of the technical team. After checking through similar apps and using the experience of some comparable projects worked on earlier, I throw the dart in the mist.
The result in majority of these scenarios is a dish served that can’t meet the expectations of the diner proving to be a disappointment, to both the parties. This is the reason I want to highlight today the importance of a specification document and how to prepare one.
So, when you have a product idea in your mind, basically in the inception stage, you have already considered these four things:
However, if these are not stated clearly when approaching a vendor there are high chances of misunderstandings; and you might end up hiring a wrong service-provider while a worthy one may slip from your hands.
Potential Problems You Could Face Without a Project Specification Document
Without a proper project specification document you will never be able to explain to the business or the technical team, what your expectations are. For instance, you might be looking for a mobile app that is similar to a leading cab service and this is all that you state in your first mail to the vendor.
With an unspecific document the vendor stays clueless about:
Stuck amidst so many queries, he ends up giving you a quote based on numerous assumptions. And you might simply reject it saying it is ‘High Priced’ or doesn’t meet your anticipations.
Well, to those who state pricing as the reason all I want to say plainly, without being rude “Quality Comes at a Price”. And to those who are not satisfied with the quote or feature list provided, even more politely I want to ask, “Was I provided the proper materials or dossier to give you a satisfying reply?”
You might feel that this is coming from an irritated sales guy who has not been able to complete his targets. But I am not the workman who hates his tools hence no reason to blame. I am in deep love with my profession, this is the reason I want to highlight the issues that my kind face.
The Right Way to Create a Project Specification Document
Well, if you are a non-technical person with hardly any knowledge of preparing a Business Requirements Document or BRD, there’s little reason to blame. Most importantly you need to consider the fact that your technical team is sitting offshore hence any gap in your specifications can lead to a greater misunderstanding than you have imagined.
However, simply jotting down your requirements and expectations does not a proper Project Specification Document make.
- Functional and Non-functional Requirements
- Functional Requirements include the features to be incorporated in the website, pertaining to the types of users and also the admin. For instance, in the above mentioned case of a sports social media app you need to mention will the registration be free for users; the posts that they can include images or videos; can they customise the look of their pages based on some personalized themes etc.
- While the non-functional requirements include points like security, customization, responsive, size and types of fonts, time to market etc. basically those components which have an indirect effect on your product. Nevertheless that doesn’t make these any less important.
- Introducing the Team to Connect with on Your Side
Mentioning the names of people responsible for clarification on any of the stated requirements is also crucial, so that the business or the technical team can arrange a call with them if any query arises.
However, when mentioning about functional and non-functional requirements I can’t help pointing out the difference between business and functional requirements, which you can read in this blog.
Benefits of Creating a Project Specification Document
It is clear by now what benefits a Project Specification Document will provide, yet it is not only for the vendor but for the client too. It helps clarify the functionalities that can be integrated and those that might not be practical in the long run, hence can be done away with or substituted.
For the business team
Moreover, with a properly specified document in hand:
- The sales and the technical team will be able to give you a proper cost estimation and deadline for the completion of the project. Therefore, if you were about to settle in for a vendor who quoted you lesser than others, you can give a second thought considering the features and functionalities mentioned in the specification document.
- The business team will be able to give you befitting suggestions about which platform and/or technology will best suit your budget and business.
For the technical team
The developer or the coders are usually programmed in a way that they carry out what has been aligned and quantified to them.
- In scenarios where the prerequisites are not stated the coders often stay confused and in turn focus on sticking to the deadline and delivering what they can make out from the meagre details shared.
- Better wireframes and prototypes can be shared with the aid of a planned project document only
However, once you have cleared stated your expectations and technical requirements to them they will be glad to take the pains of providing the best to you.
There is still another way to get these specifications calculated and computed; you can hire a Business Analyst to do this job for you. Project specification is the preliminary step that comes even before the SRS or Software Requirement Specification. Although people do not count it as a formal process but considering the rising demand for enterprises planning to go digital you need to start being more explicit in stating their project specifications.