Posted by Emilija
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.
Adrian Stolarski is a security researcher for InfoSec Institute. InfoSec Institute is a security certification company that specializes in PMP training.