4 steps to describe your project and get a credible cost estimation

Because of COVID-19 many companies have to work differently, but it doesn’t mean that they stopped working. Market leaders all the time, even during the crisis, are looking for opportunities to turn the situation to their advantage. If your business is taking a little break at the moment - use the time to work on the project you put on the shelf some time ago. Suppose you already prepared a brief description of your project, sent it to a few software agencies and you received completely different estimations. Sounds familiar?
You could go for the cheapest offer, but they differ so much that it’s in fact impossible to compare them and make an informed decision.
In order to be able to do that your project description should be created following a certain pattern. Let me try to explain that in a comprehensible way.

Please note that this is a handy, basic-level guide perfect for a quick entry into the subject. We also prepared a more advanced guide based on the analysis of what a software agency needs to give you a reliable quote, you can get it here: ABC of a quotable software project brief.


Why waste time on project estimations at all?

This is a tricky question. Is there a point to waste time (and money) on a project estimation if we could just start the project? Many meetings to discuss the scope, long hours spent discussing difficulties related to particular solutions etc. - it could be avoided if we just started coding… but this is a dead end.
In general, an estimation gives us the expected project cost and delivery time. In most cases, development is not the only part of the project. Release of the project must be synchronized with e.g. a marketing campaign which will require additional work. When we have the deadline we can prepare a schedule which will account for all those actions.


Why do estimations differ?

There are multiple reasons why the estimations differ. Below I touch upon three most frequent ones.

  1. Technology - in many cases technology and the software libraries the company is using are the deciding factor. Some companies develop projects completely from scratch while some of them use open source software. At Software Brothers, for example, we use AdminBro, an open source framework to speed up development and cut the admin panel costs by up to 80%.
  2. Imprecise requirements - the less is described the more software agencies have to guess or assume. Companies try to predict as much as they can in the estimations to make them realistic and complete, but we have to remember that the estimations as such are one of the elements of the sales process, so they should be reasonably low so that we don’t put off the prospective customers. More precise requirements usually result in comparable estimations.
  3. Hourly rate - in the end it is a key factor. A project can be estimated by two companies for 1000h and one company has an hourly rate of 20$ while the other one 100$. It's important to understand the reasons for these differences so that your choice is reasonable and supported by an in-depth analysis.


How to prepare a good project description?

I have prepared 4 basic steps to create a good project description.

4 step to define your project

1. Define the core functionalities...

First of all, you need to define core functionalities without which your project cannot be finished. For example, if you want to start an ecommerce platform, it cannot work without product presentation or payments. The same if your application is oriented around navigation - then you need integration with maps.
If you do so, not only will you know what elements you should expect in the estimation, but you will also predict most of the third party dependencies that you will need to take care of. Maps or payment gateways are not free - so remember to consider it in the project maintenance costs.

These core functionalities are like puzzles that need to be connected to create the whole project, however, it doesn’t mean that all of them must be implemented to launch the project. MVP - minimum viable product - is the solution. So, from the list of functionalities we need to choose only these that make a product users can get familiar with and benefit from.

2. … and point out what will be their advantage over competition

But MVP needs to be chosen wisely. Most of the projects (even the most innovative ones) have some similarities to products which are already available on the market. What makes for a unique product are these core functionalities.
Let’s consider ecommerce one more time - what can be unique in ecommerce? Let me mention a couple of options:

  1. High quality product - there is always a place for higher quality products on the market, especially if the prices are not too high. In this case you need to remember that premium products require an appropriate presentation - Apple websites are a good example here..
  2. Customer approach - door-to-door delivery and free returns are often good ways to attract clients’ attention, especially if the whole process can be done using the platform.
  3. Extra add-ons for the target user. Do you sell furniture? Think about a plugin on your platform that will allow users to plan their indoors.

The best way to do that is through a workshop with a UX expert. You see, your crucial, starting point is generating value for your clients. You need to know why your users should choose your product? What’s so unique about it? UX workshops give you a chance to work on that and see your product from the end users’ perspective.

We can carry out such workshops for you, but if you prefer to do it yourself then I strongly recommend running a short workshop with your team and:

  1. Define competition (you already know them).
  2. Write pros and cons of their platforms.
  3. Define what they all have in common.
  4. Point out what you want to do better and why it will be better.
define user stories

3. Define user stories using MoSCoW method

Now you can work on the priorities. A methodology called MoSCoW prioritisation will be Extremely helpful here. What does it stand for?

  1. Mo - must have - list of elements that must be included to build a working product.
  2. S - should have - list of elements that we want to include in the project because it makes the product unique.
  3. Co - could have - list of elements that are nice features, but the product won’t lose its value without them.
  4. W - won’t have - list of elements connected with the above things, but not included in the scope. For example, in the must section we mentioned payment gateways, but at the MVP stage we don’t want to include cryptocurrencies in the scope.

What does it look like in the specification?

  1. As a user I must be able to pay for my order using 2 payment providers.
  2. As a user I should be able to download an invoice on my account tab.
  3. As a user I could be able to edit invoice details on my account tab.
  4. As a user I won’t be able to remove invoice elements on my account tab.

4. Define the budget!

Last but not least, define the budget. In the worst case scenario, the company will tell you that you need two times bigger budget to deliver the MVP, so it makes sense to avoid wasting both yours and the agency’s time.
The same goes with the deadline - tell it upfront. And it’s the same situation as with the budget - in the worst case scenario the company will tell you that they don’t have resources to deliver this within the timeframe you expect.

If you define the budget, remember to focus mostly on the MVP, but keep in mind the total project budget. Projects delivered in the MVP scope can start earning money and gain feedback from the market so the final scope can be very different from the initial!


Summary

Project description should be a starting point for every new business. Define the value that you offer, try to understand your users’ perspective and don't accept the lowest estimation, just because it was the lowest.
I encourage you to put more weight on quality. If you get a few quotations - analyze exactly what lies behind them. Price is just the beginning. Always check how the company approaches UX/UI design, what technology and project methodology they work with and what the overall collaboration setup is (will you have a dedicated PM?, how often will you receive progress reports?).

Estimating cost is very important, but I believe that in a long term perspective - quality goes way above the price, so be careful and don't get fooled by discounts and "best prices".