Preparing the terms of reference for an IT development project AKA 6 steps to a new information system, online store, or web
Every proper development project always starts with high-quality terms of reference. It is often thought that the terms of reference must be as lengthy as possible, but real life has repeatedly proven that it is not the number of pages that matters but the quality of the information written on them.
We have probably all read documents during our lifetime that at first glance contain a lot of information, but for some reason actually lack the most critical information.
On the other end of the spectrum, we get queries where the potential client does not provide fully described terms of reference but wishes to quickly obtain a fixed quote. Unfortunately, no one has a crystal ball that indicates your specific needs, thoughts and wishes, so it is not possible to put together the best possible price offer for such queries.
If the terms of reference answer the most critical questions, then designers and developers can assess the project's workload in detail.
However, small nuances regarding interfaces, project implementation methodology, the technologies used, or the user interface can affect the size of a project by tens of percents, and a project that was initially considered tiny can quickly become a monster far surpassing the client's budget.
Please note that while the points mentioned in this article are necessary to create the most accurate project volume estimate possible, they do not have to be followed if we create the terms of reference together.
In that case, we will bill you based on the hours put into the task and we can work out the exact needs together, ensuring that the project can start as soon as possible.
But now, I will provide you with an overview of the most important things you should take into consideration when ordering a development project for an information system, online store, website, or mobile application.
1. Briefly write down the background information of the project.
Think about what problem you want to solve with the development and what kind of change you want to achieve. It is essential to set goals and write them down in the terms of reference. Additionally, include links to online stores /apps/e-solutions that you like and/or see as your competitors.
Goals tend to be different for each customer. In the case of an online store, the goal can be to increase turnover or traffic and reduce the bounce rate.
For information systems, it may be an increase in efficiency or overall user satisfaction by a certain percentage. However, for websites, goals may be limited to the number of visits or queries received via the web. So, think about them and write them down.
2. Write down your development budget and indicative schedule based on what you can actually make possible.
It's not nice to find yourself in a situation where what you want and what you can afford in terms of budget don’t match. However, as development projects can be done in very different ways, the budget gives us a clear overview of the project's limitations and helps us choose the best possible way to achieve your goal.
If we know the budget from the very beginning, then we can, if necessary, recommend reducing the scope of the project or changing the technology or methodology used for its implementation.
For example, it is possible to compromise and reduce the cost of development by opting for a standard content management engine for the back end, e.g. Drupal, Wordpress or similar, instead of a tailor-made one. However, it is not possible to propose a solution like this if we do not know the budget.
One of the most common mistakes made in both private and public sector orders is the conflict between wishes and budget. If your wishes are big and requirements strict, but you don't clarify the budget in your terms of reference, you can get bids that exceed it many times over.
This means that if you are preparing a public procurement, be sure to write down the estimated cost as well. Unfortunately, we have seen quite a few procurements where bids exceeding the customer's budget are presented, and the whole procurement process runs into the sand.
It is worth noting that development partners are likely to recommend setting down an indicative volume of work instead of a fixed one and to bill based on actual hours worked each month.
There is a specific reason for this. Namely, rigidly fixed costs are well-suited for situations where a specific license or ready-made solution is ordered (in other words: there is no variability), but software development means creating and inventing something new up until the very last minute, similar to how writing a work of fiction is done.
Moreover, each view that is designed and each API endpoint that is developed is unique and has its own charms and pains.
In such projects, it is most sensible to agree on an approximate scope for the project along with the activities to be done and then monitor everything on both the client’s and the contractor’s side to ensure that a workable result that makes all parties happy is reached within the given budget.
3. Think about the requirements for your project and write them down.
Functional requirements describe what the system must do and how, and non-functional requirements impose technical limitations. Requirements can be written, for example, in the form of a simple list.
Most websites usually have only a few requirements while online stores, apps, and especially information systems have more. The requirements can be, for example, the choice of language (whether there must be 1, 3, or 10 different ones), functionalities required by users, accessibility requirements, load requirements, etc.
In the case of online stores and information systems, you must provide information about any interfaces. For example, write down whether your system needs to interface with other systems, and if so, what they are, and who will develop them. For online stores, the development team must also get information about payment solutions from you.
The more interfaces there are and the more complex they are, the higher the volume of developments and the project's cost.
Don't forget to check how complete the descriptions of the requirements are to ensure that you do not end up in a situation where some of the information has been described in great detail, but the other side has been left completely neglected.
An example of this based on an online store would be to have a detailed description of how products are displayed and selected but with no mention of where the information about the products for the store comes from AKA information about whether product details are entered manually or through an information system (PIM / ERP).
4. Next, think through and write down who your typical users (personas) are.
Your client persona shows which functionality people use most and what kind of basic knowledge they have to do so. In other words, it is much easier to do both design and development if you know what type of people will use the final solution.
This way, you will get the most user-friendly web, app, online store, or information system possible. You can get a better overview of personas and other user experience mapping methods in this blog post.
5. If possible, sketch an initial prototype.
This can be a simple scribble drawn on paper or a prototype made with prototyping software, but it helps us get an initial idea of the kind of user interface you want for your information system.
If you can't sketch it yourself, we can help you with our designers and do it together during the refinement phase of the terms of reference.
Prototyping is essential for more complex projects (larger online stores, apps, webs, and information systems) as it significantly reduces the amount of improvement tasks that need to be done later on, during development.
In these kinds of projects, a more accurate assessment for the development time and costs can be given after the prototyping phase. You can read more about prototyping in our recent prototyping blog post.
6. Once the previous steps have been completed, put all the information you have gathered into one zipped archive or document and send it to us by e-mail. You can reach my team leads and I by writing to sales@twn.ee.
Be prepared for additional questions from us because perfect terms of reference probably do not exist. However, we can already give you a fairly realistic quote based on the information compiled according to the points covered in this article.
Conclusion
For simpler websites, apps, and online stores, it is possible for you to largely put the terms of reference together on your own without it becoming overtly complicated.
Just think your wishes through and write them down, and then, during the project initiation phase, we can specify them together. The easiest way to start a project is to bill it on an ongoing hourly rate basis.
However, in the case of larger and more complex information systems, and in situations where you do not have your own analyst, it is reasonable to order the compilation of the terms of reference as a separate service as, depending on the complexity of the system, this can be a very complex and large undertaking.
You can read more about our terms of reference compilation service on our services page.
At Trinidad Wiseman, we can help you during every phase of a project and do analyses, UX/UI design, branding, development, testing, and maintenance. In any case, I encourage you to write to us even if the terms of reference are not yet clear.
This is the phase where we can help you polish your thoughts and thus ensure that the starting point of the project is as good as possible since that determines the success of the project.
