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

• Mythical Man-Month
• The Manager's Path

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!