The subtleties of estimating the cost of work?

Question

Project management

Introductory.
Case times. Many here probably had to deal with estimating the cost of projects in the conditions of mm ... so to speak, limited information. Those. for example, a very vague task is set (“make a website with such and such capabilities” and only a short brief.) And in response you need to give an estimated cost. Actually, this is what happens in most cases on freelance exchanges - the customer “collects” assessments from all applicants and chooses with whom to work. So "send nafig without TZ" doesn't work.
Case two. The project is scheduled, the TOR is drawn up, and the deadlines are floating ...
What is the question.
How to learn to adequately assess the cost and, accordingly, the time of project implementation?
Please share your experience. What principles have you developed for yourself personally?
Here's what I've collected so far and what I'm trying to follow:
- the approximate (but not always adequate) cost of the project can be obtained by searching for similar projects on freelance exchanges;
– the request of any changes by the customer necessarily entails a mandatory change in the TOR and, accordingly, a recalculation of the timing and cost of the project;
- in planning time, it is worth remembering that programming itself can take ~ 30% of the time. The rest is design, testing and communication with the client;
- lay down time in the plan, taking into account the occurrence of risks ("fire, epidemic, space black holes" :)
- for me personally, for the time being - in the absence of a clear TOR, it is necessary to multiply the initial estimate by 2-2.5 (from the analysis of the terms after the fact) I.e. the initial assumption differs from reality twice.
What else would you add?
Can you recommend some literature / articles to study?

Answer 1

1. Have you tried to talk? ask what exactly the customer had in mind, how he imagines it, and generally reveal the details. As a rule, one, maximum two, letters with questions is enough to get enough information to estimate the cost of the work.
Personally, the answers immediately with the price of the application in a couple of phrases seem like spam to me.
2. Terms always float. You need to have remarkable experience and excellent professionalism to do everything as intended.
I remember admiring the teacher in general biology, who spoke vividly throughout the lesson, arranged mini tests, managed to answer a bunch of questions, and so on, but the bell always rang exactly when he finally looked at his watch at the end of the lesson. So, it doesn't work like that at work.
You can finish earlier, you can tense up and, at the expense of another activity, be on time, but there are always deviations. You can hide them using large or blurry terms (for example, “within a week”). You can lay a buffer just in case. And you can manage the deadlines normally - communicate with the customer, inform him of plans, adjust plans if problems appear or the amount of work increases, or vice versa, everything was done earlier. In the opposite direction, the customer can determine the priorities that are important to him, stimulate, if necessary, faster, or vice versa.

Answer 2

You divide the task into subtasks, set the hours for each, multiply the hours by the cost of your hour, send the estimate to the customer, the price is adequate and justified.
any changes entail changes in hours, if they need less, the product will cost less, if more, then more, everything is also transparent and understandable to the customer.
not a single person wrote how he would write habr, calculations by hours and subtasks, so everyone who wrote there can be merged. raise an analogue of habr on live street for two days with a dope, that is, 16 hours multiplied by 500 rubles 8,000 rubles, it costs an analogue of habr on live street, can be divided into subtasks and a more detailed cost estimate. This time is taken from my real experience.

Answer 3

>multiply the initial estimate by 2-2.5 I
recommend the "pi rule". Multiply by 3.14
Regarding the timing estimate. Keep statistics. A project is taken, divided into stages and tasks, each is evaluated, no matter how much. And then we take and complete tasks, marking time. Moreover, the time needs to start from the moment you start working on the task and stop when everything is completely ready (that is, so that even such small actions as starting the editor, going for a smoke) would enter at this time. After that, sit down and analyze why the deadlines did not agree and what is the average error (as a percentage of the planned one). On the next project, conduct the same tracking, again evaluate the error. And on the next one. And on the next one. After a certain number of projects, the theoretical estimate will begin to converge with the actual level of work.
I personally do not know a more accurate method than collecting statistics. And this has to be done in this form, because the same tasks by another developer would have been evaluated at a different time and he would have spent a different time on their implementation. Therefore, now only through personal statistics, IMHO.

Answer 4

When drawing up the final budget, do not forget to throw overheads. For example:
30% Testing
20% ​​Analysis
10% Stabilization
20% Planning
In general, everything that can move your deadlines. And only this final estimate and budget are presented to the customer.

Answer 5

It seems to me (and I will say from my own experience) that many customers do not always imagine what and how much it costs, as well as what time and other costs the implementation of the "customer's wishes" requires.
Great offer was above - talk to the customer. Personal contact and conversation allows not only to correctly raise, for example, the price or terms, but also is a kind of guarantee that the customer will run away to someone who is much cheaper.
You write:
- the approximate (but not always adequate) cost of the project can be obtained in the course of searching for similar projects on freelance exchanges;
I don't quite agree. I hope they don’t throw it away, but: the approximate cost of the project depends on how much the customer is willing to pay for it. That is - someone needs a small, but quickly and efficiently implemented functionality, and he is ready to pay dearly for it, and someone is diametrically opposed.
And again we come to the conclusion that the best assessment of the project is a conversation with the customer.
After all, the system for assessing the importance / complexity / business logic / payment for you and the customer is sometimes very different.
Something like this.

Answer 6

The trick is that even a READY project cannot be evaluated. I gave an example project google.com/codesearch#mORuzfPdTsg/trunk/&q=crowler%20lang :C%23 and asked various programmers to rate it. The estimation turned out from $100 to $3000 (people estimated quite seriously).
This is about a project that is already ready (we see the size, the quality of execution, and the complexity). And what can we say about a project that is not ready yet?
There are programmers who undertake to do everything in the shortest possible time and cheaply. As a result, they have nothing - neither money, nor reputation (because they constantly miss deadlines and lose projects / customers), nor the psychological strength to continue working further.
For me it was a revelation.

Answer 7

1) blurry task = 100% of the problem
2) deadlines for blurry tasks always “float”