Most people do not know how to adequately assess the timing of tasks. Oh, how it makes them sometimes nervous ... Here, and "deadline sneaks up unnoticed." And they are reinsured for over 500% just in case (still not enough). And managers trying to squeeze "knowingly bloated deadlines," so that they can promise something more acceptable(common management disease). And vague muttering instead of specific numbers(it's more of the developer's problem).
I personally, and I'm sure almost all of you, hate questions like "When would it be ready?" but they are essential at any time in a project that is considered to be under control.
So, to actually estimate time for some of your or your team's work you need to do some preparations.
Step 1. Understand customer requirements
If you don't know the destination of the ship how you can say how long the trip takes.
Start by identifying all of the work that needs to be done within the project. That includes, for example, functional and non-functional requirements(sometimes it is difficult to do at once and perhaps this process needs to be done iteratively). As part of this, make sure that you allow time for meetings, reporting, communications, testing and other activities that are critical to the project's success.
Step 2. Order these activities
Now, list all of the activities you identified in the order in which they need to happen.
At this stage, you don't need to add in how long you think activities are going to take. However, you might want to note any important deadlines. For example, you might need to get documentation of another component of the system before starting integration.
Step 3. Risk management step
List all of the assumptions, exclusions, and constraints that are relevant.
On the initial stage of the project brainstorm to identify the risk is required. The assumption that your project hasn't got any risk is wrong - every project has risks and if you do not see them then you if you don't see them, then you look at the wrong direction. When risks are not identified and not 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 about which you did not think I can materialize and increase the time for its implementation or ruin the project
Step 4. Make the estimates
There are several methods for estimating time:
Expert Judgement
Actually, this is the formation of the assessment with the involvement of experts in this required area. This may be one guru or you can attract a group of several carriers of expertise.
Experts make their assumptions about the assessment (time or $). After that, you can average all the proposals, and you can try to come to a unified solution during the discussion. Involving experts in discussing options is, of course, more effective and will give a more accurate, reasoned and tested assessment.
Three-Point Estimating
One of the most common and simple methods. Within this framework, first, optimistic (O = Optimistic), pessimistic (P = Pessimistic) and realistic \ average (M = Middle) estimates are determined.
The values of P, M and O are determined by experts (in hours, days, $), for example, during the discussion within the project team. Questions like this are asked for this: “how long will the project take, if everything goes well, there will be no risks and problems?”, “What could be the most negative scenario and how much time/effort would it take?”, etc. Further, the obtained values of P, M and O are substituted into the formula: (O + 4 M + P) / 6
The result of the calculation gives the average estimate. This formula makes it possible, on the one hand, to take into account possible positive and negative scenarios, and, on the other, to “smooth out” their influence and obtain a more realistic value of evaluation.
Cost of Quality
Quite an interesting technique, at first, time or budget is estimated only for the development of functionality, without taking into account errors and problems, as if we immediately got perfect software without defects(never seen such unicorn). And further, it is estimated how much additional time and budget will be required for work with errors and problems in reality in order to bring the software closer to that “ideal” state.
In assessing the cost of software quality assurance, you can analyze and consider the following areas:
- Expenses for defect prevention activities
- Cost of testing
- Correction of internal errors
- Fix external integration issues
- The cost of installing and configuring the software based on the real environment and data
Analogous Estimation
In the framework of this approach, we can draw on past experience in solving such problems or projects. The main step here will be to find possible analogies, highlight similar tasks.
To find friends or tasks similar to previous experience, you can do a decomposition.
Parametric Model
This is one of the most accurate and flexible assessment methods. Its essence is to build a certain parameterized model-forecast based on past experience, available data, and metrics, statistics.
In fact, a special mathematical model is built, which allows you to track how the final grade changes depending on the initial parameters. Such a dependency can even be visualized. This will help analyze the boundaries of the deviation of the estimate from the average and see what can affect this.
Bottom-up Estimation
This method is similar to an expert assessment, only in this case, the forecast is not made for the entire project as a whole, but separately for its component tasks. It is some sort of decomposition of the project to different stages. What it looks like: we collect expert opinion, for example, from specialists in analysis, development, testing, software support. We summarize their assessments together, add to them the time spent on interaction and formulate a general forecast.
In other words, we collect the assessment in parts, knowing how much time each of the participants in the software development process needs and bring everything together taking into account additional risks.
Conclusion
I think for more accurate results it may be more preferable to mix several technics, for example, bottom-up estimation with three-point estimating to estimate parts of the project.
We need to teach people to do estimations, especially in the IT field. This is important for the success of the project, for the success of the people involving in it and of course customer happiness.
It is not always possible to correctly interpret the requirements of the customer, and always expect that he will come up with something new or modify something that exists in the specifications. When a person does not want or has no time to understand the requirements or decompose the project into parts, you can always hear different factors of the multiplication support either by pi(3.14..) or by e(2.71..). The multipliers are not small and their spread can be large. But all this - the problem of inattention to the little things or laziness to understand all of the above. It is clear that the assessment requires resources, sometimes serious, but the more attentive to the trifles, the more accurate the forecast of the execution time will be, especially if we have a team that has already worked out and has carried out such projects.
Unfortunately, teaching someone to be attentive to small things is difficult and time-consuming. But it is necessary, even though resistance.
Recommended books
Thank you for reading!
Any questions? Leave your comment below to start fantastic discussions!
Check out my blog or come to say hi 👋 on Twitter or subscribe to my telegram channel.
Plan your best!
Top comments (7)
Humans are bad at estimations. There are essentially two problems here:
a) Most humans have too few datapoints in mind to make a realistic prognosis
b) Most humans are biased, mostly seeing things too optimistic
There was an insightful episode on freakonomics radio: Here’s Why All Your Projects Are Always Late — and What to Do About It
In order to improve the situation, you have to decrease the "human factor".
Thank you for your comment!
Yes, you're right - humans are bad estimators. But firstly, the project/time should be estimated anyway and secondly, by collecting several opinions your estimate more likely will be in realistic range.
How so?
If you ask people how the weather will be tomorrow, the estimation doesn't get more accurate depending on the number of people you ask. But why do we believe that to be true for project management?
Perhaps ML will improve estimations rather than humans guessing.
It's simple. It called the wisdom of the crowd - individuals may be totally wrong but the whole crowd will be quite accurate. There are several methods of ML based on this paradigm as you mention ML here =) - bagging for example
If my manager wants an estimation from me, I think of how long I think it will take. The outcome gets multiplied bij pi (like you mentioned) and that estimation goes to my manager. In most of the cases, this turns out not to be that far off. But reality forces me to admit that there is also something like Parkinsons law so my multiplier of pi might be too high.
The very reason I have a multiplier is - I think - an indication that the whole principle is wrong. If I have to multiply with a factor, it shows that I cannot safely estimate. It has become guesstimating.
Enter the management triangle:
In short: there is time, budget and quality. Any of these can be controlled by the project owner, but you can only pick two; the third one follows from the two you pick. The agile movement uses just this. It fixates time and budget, so quality follows from that. With 'quality' you can also read 'features'. Imo, this leads to better projects. The focus in agile approaches is to always have working software, so you just iterate until the project owner thinks it is good enough.
In general, software is way too complex to fully estimate in advance, so your best bet might be to accept that and use it as a basis for your planning.
It's a good point, thank you for your comment!
A better discussion on the topic than many similarly titled posts that essentially go on to say "don't give estimates. They suck." which we all know is true, but in a business setting you are unlikely to be able to just say "I start and let you know when I've finished, it takes as long as it takes". Some kind of estimate is nearly always needed in reality.