Terms of Reference (TOR) is one of the most difficult aspects in the relationship between the customer and the technical team. This is an age-old problem: customers do not know how to write it, and developers cannot work without it.
Why is this happening? Let's first understand what TOR is. In fact, it is a technical document that describes all the requirements for a product. The issue is that the developer and the customer most often speak different languages, so for one of them the TOR of the other looks like a text in Chinese. The customer thinks in terms of business, he needs a selling website. For developers, the concept of a “selling website” is useless: they need clear instructions on what elements a product should include in order to be a selling one. Similarly, when renovating an apartment, you tell the workers in detail what kind of tile laying pattern should be in the bathroom, how many sockets in the living room, how high the stretch ceilings are and what brand the windows are. If you come with a request to make a stylish renovation for you, most likely, in the end it will turn out that your idea of style and the construction team’s one do not match.
With the Terms of Reference for a website or application, everything is much more complicated: for example, it may turn out that the functionality of the service is technically unrealizable in the form in which the customer wants to see it - so the product needs to be built differently. Or that a task that seems small and simple to the customer is actually large and time-consuming. This means that the work will take longer than expected, and the project will be delayed.
How to write TOR
In fact, there is no universal way to compose the Terms of Reference. For instance, we use an interactive method, when first we make prototypes with comments, and then write the TOR based on them. This is convenient for visibility and communication with the customer. Here’s what this process looks like:
The structure of the Terms of Reference:
- Description of the project and the company: tasks that the product is designed to solve, values and requirements of the customer, corporate identity, unique selling proposition (USP) and target audience - everything that helps the development team to be in the same context with the client and make the first prototypes.
- Prototypes: the first visual sketches of the future service, thanks to which we can visually demonstrate its structure.
- Technology stack: programming language, framework, hosting requirements, and so on.
- The proposed structure of the service. For example, in the TOR for developing an application for learning English, the customer wants to see a sequence of sections with theory and practice, a dictionary, a personal account with settings, and the main page where you can select the desired lesson. Such a structure can be made in the format of a description or a diagram.
- Functional requirements for each page or screen: a description of what should happen on the screen. Coming back to the English learning app, you will see a question and three possible answers on the practice screen. After selecting one of them, the correct option will be highlighted, and then the screen will automatically switch to the next question.
- User scenarios: what happens, for instance, in case of a paid subscription and a free one. Or how the user can get information about a particular language rule through the application.
- Content: images, texts, videos, audio files for pronunciation training and more
- Final prototypes. After creating the Terms of Reference and its approval by the customer, we correct our prototypes and discuss them with the customer.
Who should be involved in the development of TOR
If the customer needs a simple information site with a feedback form, he can write the Terms of Reference for it on his own. But for a complex product with complex functionality, it is always better to compose the TOR together with the developers. This way it will be possible to match business requests with technical requirements.
And by the way, a project that the customer considers simple can be fraught with many pitfalls. Therefore, before creating the Terms of Reference, it is always better to consult with the technical team. For example, with us ;)