Each of us who has ever worked in any programming project has had to deal with one of the biggest problems we face when creating projects. It is, of course, the execution time estimate. The question about the duration of the project appears in virtually every conversation prior. Definitely as for a client, it will be also an issue that will keep each of the project managers awake at night. But the problem also applies to us. We need to ask ourselves before we start really working on the project, how much time do we really need to close the IT project? 

Most of the people I know, especially those who are not very experienced in the designing and manufacturing processes, hate making any type of estimate. This is really not surprising as making an estimate often resembles walking in the dark.

I think myself that a good estimate is half the battle. We don’t want to impose unnecessary costs on the customer or have them pay for hours of work when nothing really happens. The estimation is also useful to us, even if we are not aware of it. Any excess hours that are not included in the estimates exposes us to costs which are not covered by the customer. And these costs can really add up if you’re not careful. Note that a good programmer typically charges between 100 and 500 USD per hour so as you can see, 10 hours not included in the estimates may be a loss to the developer of up to 5000 USD.

If we can estimate the duration of the project accurately, we can make each of our customers a proposal that is realistic and not expose either us or the customer to unnecessary costs.

What do we really need to start assessing projects?

To estimate the duration of the entire project is a very difficult task. Sometimes at the beginning of the project huge problems begin to appear. In fact, at we will not really know until the end what we have to do in the project and what will be our tasks. Of course, we cannot at this stage support a lot of things, but first let’s deal with what actually happens in a formal assessment of each project.

The first stage of estimating is the foundation. Again, each assessment must be accurately described as the foundation on which the project will be created. Assumptions are made to determine all these things that are included in the project and those that have not been addressed anywhere. Assumptions must also include information about what was assumed when creating a solution to the project and if the project has any planned resources. Assumptions are essentially all factors which significantly affect the duration of the projects. It is better to take into account excess assumptions than to forget about one of the key objectives of the project. 

Another important issue with which we will certainly meet are deviations from the accuracy of the estimate. Deviations are not really a bad thing. It is through the study of deviations that we really learn to properly evaluate any IT project. Deviations allow us to realize and draw conclusions about the extent to which the forecast is accurate for our project’s duration.

From time to time, it happens that in the past we have done similar projects and we have a lot of experience in this type of project. Then we can safely bet that deviations will not be more than 10 – 25%. However, more often in the case of projects that we are doing on someone’s order, it so happens that we come to the field, which we do not have any idea. Then our estimate is really very informative. Maybe then it will reach a value of 100% of the time duration of the project. For me to estimate how much it will deviate, I developed the five-scale. Estimation is really hard to measure, and the five-scale estimates give a lot of flexibility in estimating projects. In addition, such a solution does not cause much confusion in any of the projects. The following is my scale variations. Pay attention; the greater the level of deviation, the wider is the interval. Here are my scale variations:

  • 0 – 10% – is characterized by a very low deviation.
  • 11 – 25% – is a low deviation. Overall, the scale from 0 to 25% is mainly characterized by such projects which we have had to deal with once before.
  • 26 – 50% – this type of error is usually encountered when estimating, because always when talking with a client, when I assume that the project will take, for example, two months, I say to the customer that the execution time will amount to three months.
  • 50 – 80% – high deviation, it happens when we lack the resources, motivation, or ability to move on very shaky ground.
  • 80% + – very high deviation. It happens when we lack not only resources, but also get into some wild land. In general, the deviation from 50% up it shows that we tread on one of the wild lands or create a truly innovative software. I really do not worry about when the deviation will be up to 200%. It is not really something that happens in real life very often. I really do not know the deadline, which could not be translated :)

There is another very important thing when estimating the term of validity of the estimates. In fact, it is not required, but it is recommended to always specify a valid time estimate. Everything here really depends on the purpose of the assessment. For example, let’s tell a client or manager that our estimate is valid for the quarter, as after this time we will actually add further details. Assessing the validity period is not really a protection for us, because in this way we have any protection in case someone ever showed us the archival form of estimates and wanted us to enforce them, although in the case of the project in the meantime, there already had been a number of changes which have had a significant impact on our estimates.

I find very often the case determines the validity of the time estimate, because it usually works for corporations that require a certain amount of paper documentation. Although it has never in all my life have happened to me that the data to estimate the entire project has survived unchanged. Each estimate is always updated when new data comes in, and you will see the progress of the software, or if there are any problems during work on the software.

There is yet another thing we will surely encounter when estimating the ratio between the amount of work put into the development of software and the duration of the project. This is a really important thing that you should always keep in mind and you need to be fully aware that such a thing exists. It also must unconditionally be found in any of the descriptions of the estimate. What is the funniest thing, both of these terms are commonly used to change what is really a huge mistake, and you always need to distinguish between them, if you want to satisfy all the conditions of a good estimate. Now let’s get to these two concepts.

If the workload is mostly that as well determine the number of working hours that can be spent on the completion of a project or task. Number of working hours can be safely divided between the people who work during the project. A completely separate concept is the duration of the project information. You usually count toward issues such as the availability of resources, holidays, time spent on other projects, or commitments of the members of project teams.

In the case of estimating the effort and execution time, always check what the values currently forecast, because otherwise we can meet up with some misunderstandings. Why do you think that is? Consider two examples.

In the first case, let’s say the task we are working on will take 120 hours, and we have ten available programmers working productively for about four hours a day. Why four hours? See for yourself that even though the programmer is sitting at work for eight hours, he is really effective time for four and a maximum of five working hours. For the remaining time, each project manager should take care of the professional development of each programmer, sending him for training, etc.

In that case, we define full time work for 240 hours of operation, and after dividing it by 10 developers, we get 24 hours, again divided by the duration of their work, which is eight hours and get a score of 3 working days. So the client can safely say that time we will be making corrections is 3 days.

But now I will give an example of what happens when it comes to mistakes. Sometimes we face a situation where the client simply asks how long it will take to incorporate fixes for the product. The programmer says 24 hours, so the client believes that the next day he will get the fix. And as we see the developer was talking about 24 working hours, or 3 days of work. These errors usually occur when there was hard task duration and effort of the work suffered. Then often leads to misunderstandings with the client and in extreme cases, loss of customers.

If I did not consider the estimates to be significant, I simply would not describe it here. However, since I believe that my job is to bring you all the aspects of good software development, there is a need here for articles about estimation, because next to determining the risks and management of human resources, it is one of the most important subjects in the process.

Estimation of IT projects is really important. This allows us to determine at the beginning of the duration of each project, what resources we really need to effectively produce software. In fact, the estimate is not only essential to apply to all these here parts, but very often their use can protect against problems that may arise in the process of software development. A correct estimation of project time can also significantly reduce costs and offer customers a logical business proposition, which we will be able to meet. Personally, I would prefer the company which does not specifically lower the cost to one who would say that it does, but it is not able to complete the project at a fixed cost.

About the Author

Adrian Stolarski is a security researcher for InfoSec Institute. InfoSec Institute is a security certification company that specializes in PMP training.