Estimating Projects, Part II

For part 1 of this series, please click here.

In the first part, our discussion of the estimation focused primarily on the general principles of creating any type of estimate. It also showed the importance of proper assessment to make your life easier and save you disagreements with clients and project managers. In addition, I showed that the assessment is an integral part of Agile, and may vary with the progress of work on the project.

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

This article will be a bit different from the previous one, because I will show you how you can estimate the entire project. Of course, the estimation can be approached from a few different ways, but I will describe only the methods that really make life easier. Are you ready for the next portion of knowledge about the estimation process? If so, you can relax, breathe in the nose, exhale through the mouth, close your eyes and slowly count backward from 50 to 0.. Hey, wait a minute, this is not this article. Here we go!

Estimating from the bottom-upBottom-up estimating is one of the most labor-intensive methods of estimating projects, hence it is also a method that takes the most time. This also makes bottom-up estimating one of the most accurate methods of estimating. Estimation of this type is the division of the project into the smallest task. This allows us to very accurately determine the execution time for both individual tasks and the overall project.What should we do when dividing the project into tasks? First of all, we should make such a division of labor in which the task does not exceed a few days. As optimum really takes various values. I always recommend a maximum that does not exceed one programmer 40 hours or 5 days. However, in my opinion, the ideal is to schedule tasks estimated in the range of 4-16 hours. This ensures that the customer will see the results of our work as soon as possible. The result is the addition of fields in a form, or inserting a new active component in the software. An example of the division of responsibilities for the implementation of this type of assessment is to develop a simple CMS system, where each core functionality creates a new task.Now let's see when in fact this method will be most useful during the process of software development. It is actually most efficient when planning the entire project, as soon as we make a decision about how it will fulfill the project, and we know exactly all the resources at our disposal during the project. We must also remember that we need to know all the requirements that are placed on us during the IT project. However, there are cases where this method is very hard to use, such as when estimating the beginning of each of the projects, while there is only a need to define the project, and there are no formal requirements of the project. Although it's worth it if each project is divided into smaller parts, but then, even if it is not completely useless, it cannot be used to its full extent.

Estimating from the top-down, or what to do if there is only a sketch of the project?This is the second of the best methods in estimating projects. In fact, if we combine it with the upstream estimation, it always gives excellent results. This method is mainly based on the use of any data from projects that we have previously completed. This is where there is also a fundamental problem in applying this method. In fact, if you previously did not complete any project, you will not be able to effectively make use of the method. Another problem associated with the use of this method may be that if you do not have any data from previous projects, you do not have the real-time execution of individual tasks, so you will not be able to use this technique.

So as you can see, even with Agile it is also very important to create any documentation because it contains all the previous estimates together with the results obtained in real terms, until we are able to properly use the top-down estimation.Of course, we do not need to use this method for the entire project. We might as well use it when we can only estimate the numbers of the project and not worry about anything. In the case of software design, very often we have to deal with the fact that we realize several projects similar to each other, but differing only in some additional features. So we can always use a top-down method of estimating a full assessment of the common parts of several projects. This method is usually when we are at the stage of defining the project, knowing its general assumptions. It's very good to always check with the client in preparing specifications.Parametric estimation, that is, how to define the parameters of our estimatesParametric estimation method is very similar to top-down estimation. It too uses the previous data. The only difference is in the case of using the parametric estimate of the mathematical models. How does it look? Now, let's consider a simple example. Suppose that one day we completed a similar project, and then the planning, execution and implementation took respectively 15, 60, and 35 percent of the total time in which we implemented the previous project. Since both projects are almost identical, we can safely assume that this time will be very similar.There is also a method that is completely different from the other three. It is based on the fact a that large project is estimated by converting it to the lines of code. However, the number of lines of code is inserted into the work. It is better to set up concrete panels, which are used to estimate projects using this method and include various programming languages. If I'm able to write a function using 100 lines of code, and somebody says the same thing using 500 lines, are they actually more efficient than me? And what do you do if the person estimating assumed that the project will have 75,000 lines of code, and finished in the middle of this amount? Do you have to necessarily be add in the other lines? I'm showing therefore this method only as a curiosity, although once the use of this method was really on the agenda.

What do we need to remember to create estimates?I chose a few tips to keep in mind to create the best estimates. I was able to pick them up as a logical whole. I hope that it serves many of you as a cheat sheet for creating your own projects.The first thing which comes to mind when writing this article is to use reserves in time. Always, when you count the total duration of the project, please consider a temporary buffer. The deadline cannot be extended indefinitely. It is important to understand that reserve time must be counted in order to take into account the full duration of the project, not only the duration of each task. If we think only of the time do the task, we will never know how it looks when embedded into project and how much time we have really added to the project. That's what really can make it difficult to control the project.

Note that if we estimate a project for 20 months, do not be afraid to count four months as a time buffer. In this way we have a reasonable buffer time and we are really able to determine how much time we used. But let us also not too overestimate the duration of the project, since it has a huge impact on the poor performance of the programming team. Simply put, if we can all see that we have a lot of time and that there is not really a rush, it will definitely slow down our work. Revaluation of the project also affects the lower concentration in the performance of specific tasks.

Remember, however, that the size of the buffer time is strongly dependent on the complexity of the project and the experience of the people working with it. If you ever did a similar project and have all the data on it, the buffer time should not exceed 20% of the actual duration of the project. Sometimes, however, it so happens that we do not have any experience in implementing similar projects, and the project is really complex. Then do not be afraid to set the buffer time to 40 - 60%.

We should also remember that it really is an Agile environment we live in and we can always change something. The truth is that in all the estimates you can do two things. The first is to completely remove a portion of them. However, another of the things that can easily be done is to update them. Let us remember that if we leave our estimates unchanged and if they operate on the circuit at the company where we work, the situation looks as if we ourselves set up a noose around the neck and pushed the stool from under our feet. We must prepare for the fact that no matter how much time is spent on assessing the projects, with the passage of time and the progress of the design work, it will turn out that some of our estimates need to be updated, while others do not. So after a while we will have to make a new assessment or update existing ones. Then I will describe how to do it properly.Sometimes it happens also that we do something for the first time in life. Then we have to consider one thing. For sure we will have to spend more time on it than when a task is performed once again. For example, several times already I had been doing new systems integration for a few private customers. After some time, I have written a new system and once again I had to go to several places to integrate with an existing application. In the second case, when I started working with my new system, its integration always took me a bit more time than the old system integration. From my own experience I know that always, if we implement a new solution, must allow time to learn it.Always remember to collect data and always save time spent on projects. Whenever you can only do estimates, it is an investment which will pay out for sure in the future. Estimation is really a very difficult task, especially if you do not have experience. So it is always very important for us that even the smallest projects in the estimation exercise, and even from the first draft, try to carry out the estimates.

A few words of summaryWhenever we talk about estimating projects, we are faced with a very difficult task. I really do not have, and no one ever came up with, a method that will provide perfect estimates. My articles on this topic are really only an introduction to the subject. Although it may one day come that we learn how to provide all with mathematical calculations. Still, after a couple of projects we may be able to determine reliably an estimation of future projects, and probably will have very precise control of the time of execution of individual projects.Do not be afraid to make mistakes when you make estimates, and always try to break all the tasks into the smallest fragments. This will allow us to work more efficiently with each project team. Be sure to always use the tools that you need, and do not concern yourself too much with something that will be completely useless. Is there anything else you can add?In the next article we will learn the tools you normally use when you create the estimate and the estimation of the duration of the projects. In addition, we go back to school for a while, and we will learn a few rules and a number of mathematical models that will always be useful. So far I have a modest hope that none of the articles written by me I do not need to be ashamed of. I also hope that each of them reach out all the best. Take care and I wish you to have fun browsing articles on the InfoSec Institute website.