Universities teach us algorithms and data structures. Sometimes lectures can talk about design patterns or multi-threaded programming. But I didn’t hear about how to correctly evaluate labor costs.

Meanwhile, every programmer needs this skill every day. There is always more work than can be done. Evaluation helps to prioritize things correctly and even abandon some tasks. And of course, bring big value to such issues like budgeting and planning. Incorrect estimates, on the contrary, create a lot of problems: underestimated – conflict situations, holes in budgets, overstated ones – canceling projects or looking for other workers.

To be fair, it should be noted that undervaluation is much more common in development. Why? Someone thinks that programmers are too optimistic. I will add one more reason to this: being a good programmer and being a good evaluator is not the same thing. To become a good programmer, one desire is not enough. It needs knowledge and practice. Why would it be different with the assessment?

In this article, I will talk about how my attitude to estimation of tasks has changed and how projects in our company are being evaluated. And I’ll start with how you do not need to evaluate. If you already know about how “do not”, go directly to the second part of the article.

Anti Evaluation Patterns

Most evaluations in projects are made at the beginning of their life cycle. And this doesn’t bother us until we understand that the estimates were obtained earlier than the requirements defined, and, accordingly to that, earlier than the task itself was studied. Therefore, the evaluation is usually done at the wrong time. This process can be rightly called not evaluation, but guessing or prediction, because every spot in the requirements is a guessing game. How much does this uncertainty affect the final results and its quality?

Let’s imagine you are developing an order entry system, but have not yet been able to work out requirements for entering phone numbers. Among the uncertainties that can affect the evaluation of the program, we can immediately highlight the following:

  1. Does the client need the entered phone number to be checked for validity?
  2. If a customer needs a phone number verification system, which version will he prefer – cheap or expensive?
  3. If you implement a cheap version for checking phone numbers, will the client want to switch to the expensive one later?
  4. Is it possible to use a ready-made system for checking phone numbers or, due to some design restrictions, you need to develop your own?
  5. How will the verification system be designed?
  6. How long does it take to program a phone number verification system?

And these are just a few of the questions that arise in the head of an experienced project manager … As can be seen even from this example, potential differences in the definition, design and implementation of the same capabilities can accumulate and increase the implementation time by hundreds or more times. And if we combine them in hundreds and thousands of functions of a large project, we get enormous uncertainty in the evaluation of the project itself.

Cone of uncertainty

Software development – and many other projects – consists of thousands of solutions. Researchers found that project estimates at different stages have projected levels of uncertainty. The cone of uncertainty shows that estimates become more accurate with the project progresses. Please note that at the stage of the initial concept (where are often made estimates and obligations), the error can be 400% . So it is optimal to make commitments after the completion of detailed design.

Mythical “worker-month”

There are still executives who believe that if the functionality is rigidly fixed, a reduction in time can be achieved at any time by adding staff that would do more work in less time. The error of such reasoning is in the unit of measurement used in the evaluation and planning: worker-month. Cost is really measured as the number of employees and the number of months spent. But the result is not achieved. Therefore, the use of worker-months as a unit of measurement of the work volume is a dangerous misconception. All researchers agreed that reducing the nominal period increases the total amount of work. If the nominal term for a group of 7 people is 12 months, then a simple increase in staff to 12 people will not reduce the period to 7 months.

In large groups, the costs of coordination and management increase together with the number of communication paths. If all parts of the task must be separately coordinated among themselves, then the cost of communication grows quadratically, and the “power” of the team linearly.