Statement of Work or How To Not Fail Your Project

Today, I want to talk about the statement of work (SoW). It’s also known as product requirements document, technical project, technical specification requirements, technical assignment, terms of reference, technical task and so on…

If you browse through sites, you’ll find creative and convincing articles about the fact that “product requirements document” are now dead. And well, it’s partially true – when developing a product from scratch, prototyping looks much more interesting and effective than dozens of pages about every minute detail in your SoW.

However, if we are talking about enhancing or changing an existing system as a basis of your project, then this matter takes a completely different turn. We are faced with both refinement and custom development, therefore, the SoW comes in very handy.

In general, in this article – we talk about the very classic type of SoW created to finalize a purchased and installed software.

What’s SoW?

A little bit of basic stuff – a statement of work is one of the most important stages at which the purpose, goals, and objectives of your future project are determined. The more details your SoW has, the less disagreement will arise in the future between developers and the customer. In addition, the statement of work serves to resolve conflicts and disputes, for example, failure to comply with certain conditions specified in the document or additional requirements that a customer has had after the conclusion of the contract.

What should the terms of reference contain?

First of all:

• Information about the company/customer;
• Stages and terms of the project.
• Then comes the description of the purpose, goals, and objectives. The answer to the question “Who will be the target audience of the web resource?” allows you to create a more accurate idea of ​​the tasks and goals of the site. This can be a website for customers, a corporate website for employees of a customer’s company, and the like.

Requirements for the site is an important stage that should be included in the statement of work so that the customer does not have to pay extra for unaccounted functions that he suddenly wants to install, and the developers do not have to break down the structure of the customer  suddenly changes his mind and tries to remake the project in progress.

Such parameters usually include:

• Type of the site;
• Language settings;
• Compatibility with devices and browsers (mobile version, version for smartphones);
• Design;
• CMS requirements;
• Structure and navigation.

5 Rules that we use in our everyday work

⇒ The SoW should not be greedy.

Often, a business overestimates its capabilities or wants to get “all at once.” This approach is not justified from the point of view of money, nor from the point of view of a business.

⇒ The SoW should be realistic and feasible.

It is important to listen to the opinion of the vendor because he knows exactly how much time will be spent on this or that task. Believe me, it is not profitable for a developer to waste time and stall a deadline – it is beneficial for him to complete as many projects as possible and do it well as not to get a blow to his reputation. As for realism, it is simple to avoid requests that are blown out of proportion like to create a new Tinder: you should include in the requirements what is really needed at this moment and in the foreseeable future.

⇒ The SoW should be detailed. It is necessary to indicate all the significant details of the future project: from the frequency of use of the program to the interface-related preferences.

The more detailed the requirements are, the easier and faster the implementation and testing will go. Particular attention should be paid to details if you create your dating site in a specific industry (a niche like STDs, swingers, matchmaking and etc) – a detailed presentation of the nuances of business and program interaction will ensure that the vendor understands the task and quickly adapts the system to your company.

Be sure to pay attention to number formats, field names, the presence or absence of drop-down lists, the behavior of buttons and hints, data types. If the customer uses his own formulas that need to be incorporated into the logic of the site operation (for example, calculating affiliate bonuses), these formulas should be written with a complete decoding of their designations and calculation logic.

⇒ The SoW should be unambiguous and accurate. Vague wording, implementation options, fuzzy requirements – all this is a way to a dead end.

It happens when the customer, out of good intentions, writes several options for the behavior of the system, that have close but not equivalent functionality. In this case, he is sure that he helps the programmer, but in fact, the developer must understand what exactly is needed, otherwise, he will choose how to do it based on his understanding of system features and the stack of technologies used.

⇒ The customer is not aware of the stack and technical limitations.

And he should not be – this is the task of the vendor. The customer should not delve into technology and ask at every point whether the vendor can do this or that thing. Create a comprehensive SoW and the developer will choose the appropriate architecture – often even better than you might think.

Well, I hope this will clear your doubts about what statement of work is and how it should be created.

If you want to get an example of a ready dating site and a mobile app project, you can check it in our marketplace

Here is a funny somewhat related video about SoW ↓

(1 votes, average: 5.00 out of 5)

Loading...