Estimating Projects, Part I

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. This question is - how much time do we really need to close the IT project?

Most of the people I know, especially if they are not very experienced in the designing and manufacturing processes, usually hate to make any type of estimates. This is really not surprising, because very often making an estimate resembles walking in the dark, because it is impossible to make a precise estimate of the new team, starting a new project. That's why I decided to write a few articles on estimating, and I'll show you the available methods and tools. I'll =start with simple things =that we should really keep in mind when creating all kinds of estimates. Then we will complete a project estimation, then the methods for estimating the duration of individual tasks and functionality. At the end we will talk about the tools that can help us to come to the planning and execution.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Where did the idea for this series of articles come from?

The idea came on its own, without being asked for. You have been introduced to risk management in Agile projects. I write all the time about good programming practices and human resource management. I also wanted to describe the idea of planning projects, but unfortunately I can not do without writing the introduction to the assessment and estimation for projects based in Agile.

I also want you to realize that Agile is not only the agility and that there should be some rigor in software development. Only when you fully understand and manage risks in Agile projects and interpersonal management, and evaluation for Agile projects and good code generation, will you fully understand what this agility really is, about which so much is said nowadays. By the way, you will learn to create a really good and solid software, and the same code that is well written, with all best practices, and you will be able to demand really solid payment.

I think myself that a good estimate is half the battle. We do not want to impose any unnecessary costs on the customer, nor have them pay for hours of work when nothing really happens. In addition, the estimation is useful to us, even if we are not aware of it. Any excess hours not included in the estimates exposes us to costs which are not covered by the customer. And the costs are really huge. Note that a good programmer 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 estimatingis 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.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

In the next part I will describe considerations and rules for estimating the entire project and individual tasks. Then you can move forward with your planning. Have a nice time reading the following articles.