10 mistakes when building TOR for mobile development

15-11-23

When the development of a mobile application follows a clear plan, with all requirements met and deadlines met, everyone is satisfied – the customer and the developer. The client gets a product that fully meets his expectations, and the developer spends an optimal amount of resources on it. There is mutual understanding between the parties, all problems are solved without unnecessary nerves, and the budget does not exceed its limits. This is an ideal scenario, and a competently formulated application development TOR will help you get closer to it. Conversely, a poor quality TOR can kill even the most promising project. Why this happens and how to avoid common mistakes – read the article.

Why do you need a mobile development statement of work?

A mobile application development specification is a document that describes in detail the functionality, logic, structure, and design of a product. A vague idea acquires clear features, generalized formulations turn into well-structured technical requirements for the finished product. What tasks can be solved thanks to the TOR:

• Describe the application in detail, agree on nuances, fix solutions on paper;
• Calculate the real cost of development according to the objective level of complexity of the work;
• Estimate deadlines, approve the calendar plan;
• Improve mutual understanding between the client and the contractor so that both parties have a common vision;
• Avoid unforeseen wastes of time, unplanned revisions and useless work that does not benefit the project;
• Quickly resolve disputes, if any;
• Easily coordinate work issues;
• objectively evaluate the finished product after development – it is enough to check it for compliance with the requirements of the terms of reference.

Now let’s look at some common mistakes that customers and inexperienced developers make when creating TORs.

Error 1 – Terms of Reference created without prior analysis

Before developing the TOR, you need to conduct in-depth analysis in all areas – study the target audience, competing platforms, and the specifics of the business. Next, formulate a clear and justified goal – to sell goods, to attract an audience, to entertain, to monetize, etc. Approve the concept – and only then move on to technical issues such as design, structure, and functionality. What the lack of analysis before creating the TOR leads to:

• The application runs the risk of becoming inconvenient, irrelevant to the target audience, and not meeting users’ real needs;
• The application is designed with functionality that the customer likes, but does not solve the full range of business tasks;
• The application may be noticeably losing against the background of competitors;
• further promotion becomes more difficult if there is no audience growth or if untargeted users arrive.

Professional analysis requires experience and specific knowledge, which is why our team takes this task upon itself when developing the TOR. All you need to do is fill out the brief carefully and provide quality feedback.

Error 2 – The statement of work is not detailed enough.

A specification is more than just a description of an application. It is a list of detailed requirements for all components of the product – from its appearance to the logic of its operation, where every word is clearly weighed and justified. General phrases (“beautiful,” “complex,” “stylish,” “functional,” etc.) without detailed explanations can be interpreted differently by the customer and the developer, leading to misunderstandings. For example, instead of the concept of “detailed structure” it is necessary to prescribe a specific list of sections and the logic of their interaction, to formalize these requirements in text format or in the form of flowcharts, sketches, prototypes. More detail – the development process is faster, as all nuances are agreed, there is no need to spend time on additional discussions, and the work plan is optimized taking into account the requirements of the TOR.

Error 3 – incomplete content of the statement of work

A quality statement of work contains information about all components of the project:

• Structure, number and nesting of sections, navigation features;
• Operating logic, list of functions, algorithms of component interaction in the form of user flow diagrams;
• interface, design style, page structure in the form of wireframes;
• Purpose and features of the administration panel;
• Requirements for the backend part;
• List of technologies to be used during development;
• peculiarities of operating systems for which the application will be created;
• Security and confidentiality requirements;
• Algorithms for testing and quality control.

Inadequate elaboration of at least one component lowers the value of the entire technical task, and the full implementation of the project becomes much more complicated.

Error 4 – Operating system specifics not taken into account

The mobile audience is divided into two groups – users of Android and iOS devices. Each of these platforms has its own peculiarities and requirements for applications, which must be taken into account during development. In order for an application to work correctly on all devices, separate native versions are created for each operating system, or a single cross-platform product is created that meets the requirements of both operating systems. Native development involves developing two applications for Android and iOS, which allows you to take into account all the requirements of the operating systems. Hybrid option requires a certain compromise, but it has another advantage – it reduces development time and labor costs. Before defining the terms of reference, it is necessary to make a final decision on whether the mobile application will be native or hybrid (cross-platform).

Error 5 – Custom scripts have not been processed

All decisions about the structure and logic of the application must be coordinated with user scenarios – algorithms of user interaction with the application. Without this, the mobile application may become just a beautiful picture that is not useful and does not solve the set tasks. Therefore, before creating the TOR it is necessary to answer the questions:

• How the audience behaves in the application, what paths they should take to target actions;
• What can interest and engage users to keep them in the application longer?
• at which stages there are high risks of bounce rates and how to reduce these risks;
• How to improve the interface and functionality to make the application convenient and comfortable for the audience.

User scenarios for simple applications are short and obvious – they can be described with flowcharts or text. For complex applications, interactive prototyping is required to coordinate and test scenarios before programming and design begins.

Error 6 – Changes to the approved ToR not recorded in writing

The optimal option is to develop the technical specification once and for all, with no need for changes. But no one is immune to unforeseen circumstances that force changes to the TOR. A dangerous mistake in such a situation is to limit yourself to a verbal agreement. And even if it is “just a small change,” it may lead to other unplanned changes. All of this is unnecessary aggravation, increased labor costs, and budget overruns. The more the project deviates from the Statement of Work, the less chance there is for successful, high-quality, on-time delivery. Therefore, it is beneficial for the client and the contractor not only to agree on changes to the TOR, but to prescribe and approve the changes. This will take some time, but it will save nerves and resources in the future.

Error 7 – Work schedule not approved

A statement of work is not a step-by-step guide to developing an application. Individual items of the SOW can be performed in different sequences, some work is performed in parallel, each stage requires a different amount of time and effort. That’s why the TOR documentation should be accompanied by a calendar plan specifying the main stages of work, their sequence and deadlines. Why it is important:

• The customer understands when he can see the results of intermediate stages and when he will receive the finished product.
• The contractor works according to a clear schedule, which has been developed taking into account the technical capabilities of all team members.
• In case of force majeure, the schedule may be adjusted, and the changes will be agreed upon by both parties.

Error 8 – There is no potential for application development

Constant development is a prerequisite for the functioning of a mobile application. Technologies do not stand still, the audience needs to update the functionality, new marketing opportunities appear. Therefore, when developing the terms of reference, it is necessary to determine the potential for scaling the application, to provide for monetization opportunities, various methods of promotion, integration with third-party services. What makes it possible:

• Design an architecture that makes it easy to add new features, change the structure, and adapt the logic;
• Implement modern technologies that do not limit the application’s scalability in the event of rapid audience growth;
• Monitor the performance of the application to identify problems and improve performance;
• Provide the ability to integrate with third-party services via API.

Error 9 – The customer creates the ToR without the help of the developers.

To write a TOR, it is not enough to see the application in your imagination – you need to have extensive technical knowledge related to all stages of development and functioning of a mobile product. If the client doesn’t have this knowledge, they can’t write the TOR. And even if third-party specialists are involved, they need to coordinate solutions with the developer. It is the developer who knows exactly how to optimize and simplify the development process, how to implement ideas in accordance with the available technical possibilities. And the most important thing is that the developer is responsible for the result, so he is maximally interested in creating high quality TOR.

Error 10 – The client is not involved in the creation of the ToRs

The other extreme is when the customer expresses his idea, signs the TOR “with his eyes closed” and then withdraws, leaving the technical issues to the developer. Without going into details, the client has only a generalized picture without a deep vision of functionality, structure, and design solutions. The result is unplanned revisions, complaints, misunderstandings, dissatisfaction with the finished product, missed deadlines. If the customer is interested in the success of the project, he should pay enough attention and time to communication with the developer, discuss technical issues, consciously agree on each point of the TOR.

Writing TOR should be a complex work with the participation of the client and the development team – programmers, designers, marketers, promotion specialists, business analysts, project managers. Only this approach will help to avoid unnecessary waste of time and budget, to ensure full mutual understanding between the client and the contractor, to realize the project on time and in full compliance with “expectations and reality”.