Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. — Douglas Hofstadter
Most people don't know how to adequately estimate the time it takes to complete tasks.
Oh, how that makes them nervous...
Deadlines creep up unnoticed, and they over-insure themselves by more than 500% just in case. But it's still not enough.
We hear mumbling instead of naming specific numbers, a common problem with developers. And managers try to impose "deliberately inflated deadlines" in order to promise something more acceptable to the clients - a common disease of management.
Personally, and I'm sure almost all of you, I hate questions like "When will it be ready?" but they are important at any time in a project that is considered under control. And to realistically estimate the time to do particular types of work you need to do some preparations.
Step 1. Understand customer requirements
If you do not know the ship's destination, how can you tell how long the journey takes?
Start by identifying all the work that needs to be done within the project. This includes, for example, functional and non-functional requirements. It should be noted that sometimes it is difficult to do it at once and maybe the process needs to be done iteratively. As part of this, make sure that you have time for meetings, reporting, communication, testing, and other activities that are critical to the success of the project.
Step 2. Order these activities
Now list all the actions that you have defined in the order in which they should take place.
At this point, you don't need to add how long you think the actions will take. However, you may want to mark all important milestones. For example, you might want to get documentation on another component of the system before the integration begins.
Step 3. Risk management step
At the initial stage of the project, a brainstorming session should be conducted to determine the risk. The assumption that your project has no risk is wrong — every project has risks. And if you do not see them, you are looking in the wrong direction.
When risks are not identified and measured, it means that you no longer have control over the project and the time it takes to complete it. You rely on luck — that these risks that you have not thought about can materialize and increase the time it takes to complete the project or spoil the project.
List all potential risks, assumptions, exceptions, and limitations.
Step 4. Make the estimates
Now begins the actual estimation step. There are several methods of estimating time:
Expert Judgement
It is essentially an evaluation process that involves experts. This can be a single guru or a group of several subject experts.
The experts make their judgments about the timeline. All of the evaluations can then be averaged, and during the discussion, you can try to come to a common agreement. Involving experts in the discussion of options is, of course, more effective and will allow for a more accurate, reasoned, and verified evaluation.
Three-Point Estimating
One of the most common and simple methods. This method first identifies optimistic (O = Optimistic), pessimistic (P = Pessimistic) and realistic/average (M = Most likely) estimates.
The values of P, M, and O (in hours, days, $) are determined by brainstorming with the project team. Such questions are asked: "How long will the project take, if all goes well, there will be no risks and problems?", "What can be the most negative scenario and how much time/ effort will it take?" etc. Then the obtained values P, M, and O are substituted in the formula: (O + 4 M + P) / 6.
The result of the calculation gives a close realistic estimate. This formula allows, on the one hand, to take into account possible positive and negative scenarios and, on the other hand, to "smoothen" their impact and obtain a more realistic assessment value.
Cost of Quality
Quite an interesting technique. Estimates are made just to develop functionality, without considering bugs and problems, as if we would be implementing perfect software without defects right away (I've never seen such a unicorn). And then we calculate how much additional time and budget it would actually take to deal with bugs and problems to bring the software closer to that "perfect" state.
In assessing the cost of software quality assurance, you can analyze and consider the following areas:
- Expenses for defect prevention activities;
- Cost of QA;
- Correction of internal errors;
- Fix possible performance problems;
- Fix external integration issues;
- The cost of installing and configuring the software based on the real environment.
Analogous Estimation
Here we rely on past experience in solving such problems or projects. The main step here will be to look for analogies and identify similar tasks that have already been completed by the team.
With this approach, you need to decompose the project into tasks that are already known to the team and have been solved in the past (or lead to similar tasks), and unknown tasks that can be estimated in another way.
For example, if a few months ago website development cost 8000, and you needed to develop a new similar website, your estimate would be that it would cost ~8000.
Bottom-up Estimation
This method is similar to Expert Judgement, only in this case the evaluation is not made for the project as a whole, but separately for its parts. This is a kind of decomposition of the project into different stages. We collect expert opinions, for example, from specialists in analysis, development, testing, software support. We summarize their assessments together, add to them the time spent interacting, and formulate an overall estimate.
In other words, we put together an estimate piece-by-piece, knowing how much time each of the participants in the software development process needs and taking into account additional communication costs and risks.
Parametric Model
The essence of this method is to build a certain parameterized forecast model based on past experience, available data and metrics, and statistics. It is somewhat of a cross between Three-Point Estimating, Bottom-up Estimation, and Analogous Estimation.
We build a special mathematical model that allows you to monitor how the final estimate changes depending on the initial parameters. This dependence can even be visualized. This helps to analyze the limits of the deviation of the score from the average and see what might be affecting it. For example, if last week it took me two hours to complete two tasks, and this week I have four tasks, I estimate that it will take eight hours, assuming the tasks are more or less the same.
This is one of the most accurate and flexible estimation methods because it relies on historical data and industry standards.
Conclusion
It is not always possible to interpret the customer's requirements correctly, and one should always expect the customer to come up with something new or modify something that exists in the specifications. When one is unwilling or unable to understand the requirements or to decompose the project, one always hears different valuation multiples of either pi(3.14...) or e(2.71...).The variation in the multipliers can be large, leading to a misunderstanding of the completion time. But this is a problem of careless attention to detail or unwillingness to understand the project.
It is clear that estimation requires resources, sometimes significant resources, but the more attention to detail, the more accurate the completion time prediction will be, especially if we have a team that has already designed and implemented similar projects.
We need to teach people how to make estimates, especially in the IT field. This is important for the success of the project, for the success of the people involved in the project, for the success of the final product, and of course for the satisfaction of the customer. Unfortunately, teaching someone to pay attention to detail is difficult and time-consuming.
Buy
me a coffee