There is no exact word for it. While I was choosing a name for the article, I googled a lot of versions: Statement of Work, Scope of work, Job Specification, Technical assignment, Software Requirement Specifications. So here we will talk about the situation when you have a request from your customer. You have to somehow clarify, write down, understand the task from a development point of view (what needs to be implemented) and implement it.

To create Terms of References, you should find out what needs to be implemented. Start with trying to understand which problem the client is trying to solve. Often client offers to develop something which won't resolve an issue. So it's better to start by speaking.

Speak

Speak with the customer about the thing they want to develop. Record the conversation. When details are not precise for you, ask clarifying questions. Speak for 30-45 minutes, not more. Or all of you will start to lose attention.

During the session, find the people who will be your connection link during the development and implementation.

Tell about MVP

When time passes (30-45 minutes), don't hesitate to stop the conversation politely. Tell them about MVP conception when everybody cools down (if there is more than one person, the conversation usually gets hot over time).

Minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.

Give some examples of MVP, like:

• Amazon MVP: an online bookstore

• Airbnb MVP: a room-exchanging platform in one house

• Dropbox MVP: video about how Dropbox worked (there was no platform, only a video)

It's better to start from MVP. It's cheaper for a customer. It allows the supplier to dive deeper into the project before the extensive work starts. Also, usually, the customer significantly changes the concept in the implementation process. And if we use the MVP strategy, we will give the customer time to gather more thoughts and decide better on an idea.

Decide on the MVP

When everybody understands what MVP means, try to ask them what should it be in your case. Usually, no one from the customer could decide on MVP concept. After 2-3 attempts, offer your point of view. Make it as simple and as short as possible. Your customer will try to add some features to it and even say that it would not be helpful without it.

Be patient and clear about your goal. The goal - is to test the idea of the task with a minimum effort.

You can read more about how to plan an MVP here: Planning a Minimum Viable Product: a Step-By-Step Guide

Acceptance criteria

Here you should also discuss acceptance criteria. Ask your customer to prepare a list of actions/things they would check to ensure the MVP works as needed. If the customer can not do it, develop it according to the information from the next step.

Here you can find the guide on how to create detailed acceptance criteria

Timeline

When you decide on MVP, the customer will ask you what time it takes. Don't answer! Take a couple of days to decompose the task, and translate it into technical language. During it, you will find questions, so get in touch with your connection link's people and clarify.

During planning, it's good to use the Gantt chart. Usually, you would have task dependencies (situations when a new task can only be started once another task is completed). If the previous task is delayed, then dependent tasks should be rescheduled.

So, first of all, you should split the main task into small product tasks. For example, if you are doing MVP for Airbnb, you would have tasks like registration in the app; user's personal account; interface for choosing a room; possibility to add a room to the user, etc.

Secondly, we would split product tasks into technical. Try to make tickets (each ticket is one technical task) that each one would not take more than about a day to complete. It would help you to measure the MVP more correctly. Don't forget some tasks could have dependencies and could not be implemented simultaneously. Also, don't forget about tickets for tests, deploy, setting up a test and product stand, and monitoring (if needed).

When you would finally count the timeline remember about holidays, vacations, possibility that someone can get sick.

Contract

If the customer agrees on a timeline, you should decide on organizational matters. Clarify and write down:

• Timelines for answering questions during implementation and responsible persons
• Who would provide and pay for hosting (if the customer, who would deploy the app)
• Define the time for acceptance and it's the procedure
• If there are some security specifics
• If there are some specific criteria for fault tolerance
• Requirements for monitoring
• Requirements for DevOps
• Documentation requirements (format, language, etc.)
• Any API criteria
• Any programming languages requirements
• How to send source code
• Period of warranty support (its format, response speed)
• feel free to continue the list

If there are a lot of new requirements, you have to reevaluate again.

Implementation -> Demo -> Implementation

Just do a small part and show it to a customer. It's good to show the progress once in 2 weeks, for example. Just a meeting for 15-20 minutes where you tell what have you done and what are you gonna do for the next 2 weeks. It makes your work transparent and adds more trust in relations with the customer.

Suppose the customer wants to change criteria during the implementation. In that case, you should re-do the time measurement and adjust the contract and acceptance criteria. Make it straightforward for customers how even a small change would affect the project implementation.

You can find more about methodologies here: What is Agile?

Acceptance

You'd better have acceptance criteria in a written form (approved by your customer), because it would be easier to pass through acceptance. Because usually, at this point, the customer remembers what they lost during the declaration of MVP. And often, they would say that they spoke about it and would claim it has to be done.

Of course, together, you would find some bugs and other stuff, so you would have to take time to fix them. It's OK and happens all the time. After it, you will have to repeat the acceptance process. Just when you plan on the timelines, it's better to remember about it and don't agree to do the next project immediately after the end date of this. Otherwise, you are gonna get stuck in deadlines.

Congratulations!

When your work is submitted and accepted, you can go on with the next project or with the same one but with other features. This instruction also works for such a process. Find out the following scope of features, prioritize it, select the next block and make new contract and acceptance criteria. Hope it was helpful. :)
And if you have ideas on how the article could be extended - contact me or comment on it.