Life hacking: in any incomprehensible situation, multiply by three

The article was written three years ago, but it was gathering dust in the drafts. Publish without changes. Much water has flown under the bridge since that time. However, my experience may be useful to someone.

---

I want to discuss the problems associated with a preliminary estimate of the time and timing of projects. In this article I will tell you how things are on the project, which I have been conducting for a little over 5 months. I will give some of my thoughts, explain what experiments with the estimates I did and what conclusions I received after this period.

But first, a few words about yourself. I am 26 years old, I have been working in a current company for a little over four years. The company is a typical outsourcer headquartered in the states. Before that (from 2002) I changed 3 web studios.

Fixed Fee vs Time & Material

It so happened that in our company they do not like Fixed Fee projects. There are many reasons for this, but, by and large, everything depends on an incorrect initial estimate of both the budget and the time frame. This resulted in failed periods and losses. Therefore, we tried our best to do all projects according to the Time and Material scheme - we counted how much time was spent and multiplied by the cost per hour. In this case, we risk nothing when we have fundamentally wrong budget estimates. In the worst case, we tell the customer “Sorry, we were mistaken in our assessment. We did not take into account this and this, besides you wanted to redo this and this. Therefore, your project will cost you X times more. ”
')
However, not all customers are satisfied with the situation when it is impossible to predict the budget. And I understand them. What kind of financial planning in a company can we talk about if you don’t know how much “site creation” will cost you? Our experience has shown that the only effective case for the success of perpetual projects is when your services cost the customer relatively cheaply and they are happy to post some small amount every month. This is reminiscent of the situation when you do not have enough money to make repairs to the whole house. And for years you have been repairing parts in installments - little by little each month, as far as enough free money is enough.

Such projects can drag on for a very long time: the customer constantly has some ideas and changes. You fulfill them, then new ideas are born, and so on in a circle. As long as he easily pays the bills.

However, this does not apply to new projects. The customer wants to see the result as soon as possible. And, of course, spending as little money as possible.

Social network

So when the customer came to us and said that he wanted to know how much it would cost to make a “social network”, we smiled. There has been a trend. The fact is that before that we did ... also a social network.

We said that it would take about 3-4 months from 4-6 developers and multiplied the figure by our hourly rate to outline the budget order. If you need to attract a new customer - this option almost always works (if they have a really big project) and they agree to start development.

When it turned out that the client does not agree to any Time and Material, I no longer smiled. There was no time for jokes. The task of assessing the budget of a social network with fuzzy requirements is, to put it mildly, non-trivial.

Another interesting fact was that the customer began to develop in another company, where he did the whole design, put most of the pages in HTML and made an initial assessment of the further cost of work. Then they didn’t get along and somehow found us. Thus, we had a ready-made design, partially ready-made HTML (of relatively tolerable quality) and a list of system functionality.

We decided to take this list and estimate how much time it might take on each of them. My American colleague applied the following methodology: 8 hours per page + some number of total hours (40-120) per individual subsystem. So, if for personal messages 5 different pages were compiled, then this resulted in 80-100 hours of work.

Yes, this estimate was very rough. Later, I calculated that it differed from the actual hours spent on average 2.25 times. Immediately I was very unhappy with this assessment and understood that it was not adequate. However, the usefulness of this assessment, I realized later. For a more detailed assessment, it is necessary to spend many days looking at each possibility of the system, linking them together, taking into account all possible nuances in border conditions, etc. And this is virtually impossible to do - there is no documentation or technical assignment, nor will there be The customer discussed everything with the previous team and he constantly has the feeling “we have already discussed this”. And he believes that from the layouts you can find out what and how the system should do. Over time, I realized that a bad and rough estimate is better than its absence. A good estimate in many cases is simply impossible to do. The project in the process of its development is constantly changing. The requirements for its functions, appearance, etc. also change. Accordingly, the initial assessment should change. And that is why the initial deadlines and budgets simply cannot be accurate.

Although there are exceptions. One of our projects is a risk accounting system for a very large Swiss bank. Their bureaucracy is just perfect for us. They first approve all necessary changes, clearly document them and only then send them to us for evaluation. In this case, we can accurately calculate the estimate for all the requirements are known, everything is clearly documented and nothing will change before the delivery of the project. But this is extremely rare. It is rather an exception to the rule.

Estimate

So, in drawing up a budget for our social network, we decided to take a different course. We decided to make all the functional systems separate phases. Each phase is discussed, evaluated and approved by the customer immediately prior to its implementation. When we made up the idea of ​​a set of tasks, we could already quite accurately estimate the time for their execution and make a commercial proposal for these tasks. Thus, we got something in between Time & Material and Fixed Fee.

Previously, I didn’t have much to do with Fixed Fee projects, and therefore it was extremely interesting to learn how to soberly evaluate them. Among the developers constantly went jokes like "take an estimate, multiply by two and better three and get what you need." Jokes - jokes, but how is it really? That I had to find out.

I used to crush tasks into the smallest subtasks, evaluate them, add up the amount, multiply by magic numbers (add 10% for deployment, 10% for testing and 10% for management & communication). The resulting figure multiplied by the current cost of an hour of work of the developer and voiced the figure to the client.

If something went wrong, it was not critical - after all, it was only an estimate of the cost of the project and we worked on Time and Materials, so the loss simply could not happen. The client will pay all in any case. With Fixed Fee this does not work out. The man said - the man did. Said what you do for $ 5000 - be kind for $ 5000. Even if it took twice as long as planned.

Therefore, after completing the first set of phases (they were made by different people), I began to collect all the data for statistical analysis and built all sorts of interesting graphics for me.

Problem

The first figures showed that the case - rubbish. We are at a loss. But why?

The first estimate was lousy. It was obvious. In addition, the American leadership in the process required that the site was completely AJAX without a single page overload. And we did not take this into account in the assessment. We thought that we would make several separate pages with our ajax calls. And we were forced to rework many things so that there would be no page overload at all.

Thinking, I increased the coefficients and added another new one - profit. I added it under the influence of some article, whether on a habre or somewhere else. After all, in addition to wages, we must get more profit, right? :) With the new coefficients, we have completed three more phases (they went in parallel). Along the way, I was working with developers, trying to find out the causes of delinquencies and eliminate them. Upon completion of these phases, the graphics showed that we stopped losing money at such a crazy pace. However, the developers still spent more time on completing tasks than estimated. This interested me. Why?

Deadlines

I observed the following picture. The developer receives the task for 8 hours. And he spends 8 hours on it. Exactly 8 hours. Sometimes more, but almost never less. Then it shows the result and this result needs some work. I send it to redo it and after the second or third iteration I get a satisfactory result. By this time, the dates have already been exceeded. Requests to show in advance, etc. had no effect. And I went to the trick - I underestimated the time allotted to the task.

At the 8-hour task, the estimate of underestimation for 1-2 hours was not noticed by anyone. Allocated six hours - the developers still spent six hours, came and then finished it. So we began to somehow invest in time. Then I went ahead and came down to half the time. And it worked! Sometimes, however, the guys started coming and complaining that they would not have time to complete the task in such a time frame and they would need more time. I asked how much, they answered that it was 1-2 hours more, they received my consent and made it in this new term. And in the end - it turned out that they did faster than the initial estimate. Percentages are 10-15% faster, and not 15-20% longer as it was before. However, this did not affect their mood very well. They were tense and nervous because they did not invest in the allotted time. I decided not to play so drastically with the deadlines and just lower them by a quarter when I fill in the task accounting system.

The next step was the transition to the assessment of the task by the performer. Previously, I myself estimated how much time the task would take and set the deadlines myself. Over time, I moved to the scheme when I just make a list of tasks, we discuss them and the developers say how long they will take to implement them. Thus, I got rid of phrases like “We do not value tasks! That's why we don’t invest in the deadlines! ” Now they evaluate their tasks and they are very honest in demand if they have frustrated the deadlines. However, how to understate the term that the developer himself has chosen? I transferred this understatement to the coefficients, which later multiply the total amount of hours.

Total

Gradually, after all iterations and trials, we left the loss phase and moved to the money making phase. Now we have almost completely compensated for the initial losses and are about to move on to net profit (we get an hour's worth more than with Time & Material). And you know what I concluded after 5 months of work on this project? If you want to make money, multiply the preliminary estimate by three.