There is one aspect of today's software development industry that many experienced programmers are sure to bring back bad memories of headaches due to having to finish a project before a deadline, working overtime, etc. when mentioned. We are talking about the timing and time estimate, or rather, the number of man-hours that are needed to complete the project. According to experts, and it's hard to argue with them, estimating the amount of time to develop certain projects is just the Achilles' heel for many, if not most developers. According to researchMcKinsey, 66% of enterprise software development projects cost more than originally planned. Of these 66%, a third go beyond the original schedule, and about 20% do not fulfill the tasks and goals at all. That's not all. The researchers found that 17% of all IT projects in practice are implemented so differently from the original plans that they begin to threaten the very existence of the company. And the total amount of cost overruns due to incorrect estimates when planning projects is completely colossal. “As part of a joint study, McKinsey and Oxford University analyzed more than 5,400 IT projects in various industries. By comparing budgets, schedules, and predicted performance improvements with actual costs and results, we found that that the total amount of budget overruns during the implementation of these projects exceeded $66 billion - this is more than the GDP of Luxembourg,” the study says. “We also found that the longer a project is scheduled to take, the more likely it is to run over time and budget. With each subsequent year of work on the project, the cost overrun increases by 15%,” the analysts add. In today's article, we will talk about how to estimate development time most effectively and what to pay attention to in the first place. And also learn how experienced developers advise to approach the estimate. the more likely it is to go beyond time and budget. With each subsequent year of work on the project, the cost overrun increases by 15%,” the analysts add. In today's article, we will talk about how to estimate development time most effectively and what to pay attention to in the first place. And also learn how experienced developers advise to approach the estimate. the more likely it is to go beyond time and budget. With each subsequent year of work on the project, the cost overrun increases by 15%,” the analysts add. In today's article, we will talk about how to estimate development time most effectively and what to pay attention to in the first place. And also learn how experienced developers advise to approach the estimate.
Methods for estimating the time for the implementation of software projects
1. Comparison with already implemented projects (analog method)
Finding an already implemented project with the most similar functionality and taking the time it took to implement it as a basis is one of the classic methods of estimating. One of its main advantages is that when considering an already implemented project, you can see how much time was allocated for its development initially, how accurately this plan was implemented, what difficulties the developers faced and at what stages. To facilitate the evaluation process and increase the overall accuracy of the estimate, the overall project is often divided into a number of components, the implementation time of which is estimated separately (method by parameters).
2. Team evaluation
This method is also called the “poker method” in some English-language sources. It is based on an independent assessment of the implementation time by different members of the programming team, as well as business analysts. Everyone makes their assessment, after which the results are compared and discussed. Those who were the author of the lowest and highest of the estimates give their arguments in favor of this point of view, and during the discussion, the team seeks to establish a realistic and adequate time frame.
3. Bottom up and top down
Within the framework of this method, the main task of the project is divided into smaller ones. So that each of the tasks can be estimated with sufficient accuracy. After that, the time required for the implementation of each task is summed up, which gives the final estimate. At the second stage, the project is already evaluated as a whole. If the difference between this estimate and the one obtained after the first stage with division into small parts is too large, the team analyzes the reasons and works on a compromise estimate.
4. Third Party Evaluation
For those teams that find it especially difficult to determine an estimate when evaluating a project (or disagreements among team members cannot be resolved), there is an option to contact a third-party team that will be able to look at the project from the side and issue a more balanced and objective decision.
5. Triple score
Within the framework of this method, the team forms three options for estimating the time for project implementation: optimistic (O), pessimistic (P) and closest to real (P). Further, the final score is calculated according to one of two formulas: (O+P+R)/3 or (O+4R+P)/6.
Tips and opinions of experienced
1. Individual estimates cannot be transferred to other team members without changes
As many experienced developers point out, when planning, you need to remember that different programmers differ greatly in abilities and experience, both from an individual point of view and in working with certain languages and technologies. This is one of the main reasons why it is very difficult for companies and development teams to accurately calculate the time for the implementation of a particular project. Therefore, when estimating the time it will take a team member to complete a job, the individual level and experience of each developer should be assessed, not the “average temperature in a hospital.”
2. Plan 15-20% more time to hedge against risks
Another common advice is to put 15-20% more time into the official plan than the original estimate requires, to insure against possible time overruns in the event of unforeseen problems and delays. The most risky in terms of time costs, as a rule, are the most complex and / or most incomprehensible parts of the project.
3. Don't forget about the time it takes to communicate
In his bestselling book Manage the Unmanageableon managing a development team, authors Mickey W. Mantle and Ron Lichty state that, on average, developers spend only about 55% of their time on coding, while the remaining 45% they spend on interaction and communication with colleagues, managers, testers, designers, client representatives, etc. In addition, experts write that only one-sixth of the total time spent working on a project falls directly on writing code. Half of the time, or even more, is spent on testing and fixing bugs. Therefore, experienced developers are advised to always remember these statistics and take them into account when drawing up plans. This is especially important for teams that have a lot of developers. It has been observed that adding new encoders to the team, as soon as their total number begins to exceed a certain threshold (usually 5-6 people maximum), it inevitably starts to slow down the work on the project as a whole. This is due to the fact that it always takes a new developer some time to get to know the team members and the already existing project code.
Timely correct errors in estimates
“Updating and adjusting the initial estimate after the project is up and running is perfectly normal. The more information the client provides, the better you understand how many man-hours it will take to implement it. And the sooner you understand that the plan needs to be adjusted, and do it, the better. Feel free to discuss this issue with the client, even if you need to move the deadline or add new specialists to the team,” advises Sergio Acosta, an experienced developer of multi-platform applications. “Of course, first of all, a project manager or team leader should follow all this, but in reality they often cannot do without the participation of ordinary developers. Especially in cases where the project manager / team leader is involved in several projects at the same time or is too busy,
5. Options for estimating project time for a client should not differ much
If you send a client two or more estimates (for example, the optimistic, pessimistic and realistic ones mentioned above), make sure that they do not differ too much from each other in terms of allocated time. According to experts, the time difference between the options should not be more than 20%. If it is more, it can scare and repel the client, who will not know what to expect. The only case when significant fluctuations in the estimated time for the project are acceptable is if the client provided very little information about the project, and it is not possible to accurately estimate the resources for its implementation.
6. Evaluate different types of project work separately
Also, experts advise to evaluate key types of work on the project separately. This will help increase the accuracy of the estimate and quickly calculate its weaknesses. So, separately it is possible and even necessary to evaluate the following types of work: coding, design, analytics, management, QA and testing, code analysis, creation of documentation and user manuals, automation, etc.
Instead of an epilogue
However, some experts believe that estimates in the field of software development are evil, and they should be completely abandoned, at least in a strict form. About this in his article Software Estimation is a Losing Gamewrites Richard Clayton, Senior Developer at LotMonkey. “Do we need time estimates when developing software? I've asked this question to project managers and corporate bosses on numerous occasions when I was asked to do an estimate for a client with absolutely no information or understanding of the tasks. “Of course they are, because otherwise the client will not sign a contract with us,” they answered. And, unfortunately, this is the correct answer. It's correct because we allow the system to work that way even though software development is a poor fit for the system,” Clayton writes. “In reality, the development team can only implement a set of features in proportion to the amount of time and resources that have been allocated. In a sense, in this we are similar to the tourism industry - we cannot guarantee the guest, that in a week in our resort he will have a great rest and fully recover. All we can do is promise that the longer the guest stays with us, the more rested he will leave,” the expert believes. Write in the comments what you think about this. What estimation methods do you think are the most effective, do you like the current approach to project evaluation, and is it worth radically changing this system, as Richard suggests?
According to experts, and it's hard to argue with them, estimating the amount of time to develop certain projects is just the Achilles' heel for many, if not most developers. According to researchMcKinsey, 66% of enterprise software development projects cost more than originally planned. Of these 66%, a third go beyond the original schedule, and about 20% do not fulfill the tasks and goals at all. That's not all. The researchers found that 17% of all IT projects in practice are implemented so differently from the original plans that they begin to threaten the very existence of the company. And the total amount of cost overruns due to incorrect estimates when planning projects is completely colossal. “As part of a joint study, McKinsey and Oxford University analyzed more than 5,400 IT projects in various industries. By comparing budgets, schedules, and predicted performance improvements with actual costs and results, we found that that the total amount of budget overruns during the implementation of these projects exceeded $66 billion - this is more than the GDP of Luxembourg,” the study says. “We also found that the longer a project is scheduled to take, the more likely it is to run over time and budget. With each subsequent year of work on the project, the cost overrun increases by 15%,” the analysts add. In today's article, we will talk about how to estimate development time most effectively and what to pay attention to in the first place. And also learn how experienced developers advise to approach the estimate. the more likely it is to go beyond time and budget. With each subsequent year of work on the project, the cost overrun increases by 15%,” the analysts add. In today's article, we will talk about how to estimate development time most effectively and what to pay attention to in the first place. And also learn how experienced developers advise to approach the estimate. the more likely it is to go beyond time and budget. With each subsequent year of work on the project, the cost overrun increases by 15%,” the analysts add. In today's article, we will talk about how to estimate development time most effectively and what to pay attention to in the first place. And also learn how experienced developers advise to approach the estimate. 
