A successful project starts with efficient estimation and proper pricing. In this article, we will focus on the first factor because it is crucial, due to its impact in terms of planning work on the project.
Based on the publication and experience of one of our Project Manager - Agata, who runs an interesting blog zwinna.com herself, we would like to explain what IT project estimation is, why it is so important and what are the common problems with estimating IT Project.
Table of Contents:
1. What is the IT project estimation process?
2. Why are project estimates important in IT project management?
3. What types of estimations take place during a project?
4. When Should Estimates Take Place?
5. The Most Common Problems with Estimating IT Projects.
6. Estimate Review.
7. Summary.
What is the IT project estimation process?
Estimation of IT projects is an attempt to determine what functionalities a product should contain to provide value to users and meet customer expectations, what is the level of complexity of individual functionalities and how long it may take to implement them, and thus what is the projected cost of project implementation.
IT project estimation is a difficult process. Simultaneously, estimation is required in order to make strategic business decisions for a given project. It enables to determine whether a particular project is worthwhile to implement, whether it will reach users during the appropriate market window, and whether it is the best solution to a particular problem.
Why are project estimates important in IT project management?
With a project estimate, it is possible to form a general idea of how much time, effort, and money it will take to complete a specific task that is a part of the IT project. This makes it easy to build a workable budget and project plan that allow to prepare the whole project team and organization for success.
What types of estimations take place during a project?
There can be distinguished 6 main types of estimation:
- Cost is one of the most important aspects of a project because when there is not enough money to complete the project, it will fail. Estimating in this case is about predicting how much money will be needed to make the project successful.
- Time refers to the overall amount of time it'll take to complete the project and accompanying tasks.
- Scope is all the work that needs to be done on the project for it to be successfully delivered. During this estimation, the development team has to estimate how much work is required to get the final product.
- Quality focuses on how well the products delivered are completed and how well they meet specific regulations or expectations.
- Risk is an unexpected event that could have a positive or negative impact on the project. Estimating risk entails predicting what events might occur during the project's life cycle and how serious they might be.
- Resources are everything you need to complete your project, including team, materials, equipment, etc.
When Should the Estimation Take Place?
In a traditional project (Waterfall), the planning phase occurs right after the project has started. At this stage, cost estimates will be created and documented for all aspects of the project. Estimates can also be revised and updated during the project as new information becomes available.
Agile projects, on the other hand, have a more iterative approach to planning and are usually divided into iterations or sprints. In this case, the estimation is performed initially during the creation of the general list of features and requirements, and then again during each sprint.
The Most Common Problems with Estimating IT Projects
#Problem with Getting an Accurate Estimate at the First Estimation Stage
Project and product knowledge grows as the project progresses. Assuming that the project is implemented based on Agile Methodologies, each sprint provides us with new information about the product and project, regarding cooperation, strengths and weaknesses of the team, etc. At the beginning, this knowledge is small, and this results in the fact that the uncertainty is high.
Already in the early 1980s, the first version of what was called the "cone of uncertainty" in the late 1990s was created. It shows that at the first estimation stage, the rating usually varies between 60 and 160%.
According to Agata based on her experience so far, it's more often closer to 160% than 60%. The Project Management Institute suggests that the ranges should be as follows: 75% - 175%. This cone narrows as the project progresses. After several sprints, when our knowledge of the project and product is greater, the original estimates should be re-estimated.
Thanks to continuous inspection and adaptation, project stakeholders have a transparent picture of the situation. This affects the quality of the relationship we build with them and increases their trust.
Avoid that after a few months of work they will be surprised at how much is left to be done, i.e. how much extra time is needed to implement the project and additional financial resources.
For example, if at this stage we get an estimate of 25 weeks, then from the uncertainty cone we can assume that the work will take between 15 and 40 weeks.
#Estimate as a Specific Value, not as a Range
This point is closely related to the first one. It very often happens that a specific value, e.g. 20%, is added to the obtained estimate, e.g. using an expert method, as a buffer. The client then receives information that the implementation of a given project will take about X working days. Providing one specific value may give the client the belief that it is our commitment because we provide a specific number.
Let's see it on an example.
The expert estimate is 100 man-days (MD), and the settlement type is time & material. A 20% buffer is added to it, so the estimate given to the client is 120 MD. After 130 MD, he finds that he still needs extra time to complete a few tasks in the project. It is estimated that it will be at least 10 MD.
Probably the client is very annoyed by this fact because he expected the project to close in 120 MD. Meanwhile, it turns out that 130 MD have already been burned and more are needed. How much finally? This is not entirely known.
When deciding to pursue this project, he had no clear information on how much the original estimate might deviate from the final amount of MD needed to complete this project. He probably based his decision on the estimate of 120 MD and assumed that such a budget could be allocated to this undertaking.
What would happen if the cone of uncertainty was used here? The originally estimated 100MD would have been presented in the range of 60MD - 160MD. The client would be told that given the uncertainty and the current phase in which the estimate is being made, the project could cost as much as MD160. Knowing the limits of the range, he can make a more informed decision. It is also then possible to develop a solution that would be satisfactory for the customer. e.g. revising the scope, using the functionality buffer, etc.
#Estimate - How to Communicate It
How the estimate is communicated is of great importance. Especially big for a client who doesn't have much in common with the IT industry and may not understand what an IT project valuation is and what elements affect it. The estimate can be compared more to a weather forecast than a hairdresser's price list. We check the weather forecast - even the long-term one and make plans based on it, we make decisions. However, we know that the forecast does not guarantee that the weather will be exactly like this and that we will be able to implement our plan. This is different from when we go to the hairdresser, and we know in advance the price we will have to pay for the service. Nothing here will surprise us at the end - maybe apart from the effect, sometimes. We value transparency very much, which is why it is significant for us to clearly present the estimate to the client. The client should know that the estimate is a forecast and not our commitment, and should know the extent of that forecast.
#High Level of Uncertainty
Estimating a project at the very beginning is difficult because the level of uncertainty is very high. Uncertainty is not limited to what we do not know about the application that the client wants to make. It is obvious that we will not know every detail of it at this stage, and sometimes such a detail has a big impact on the estimate. Uncertainty is also induced by rapidly changing markets. It may turn out that an element of the application valued today will require redefinition at the time of implementation due to new market circumstances. The estimate can be protected against the risk of inconsistency using, for example, a feature buffer (more here). They were perfectly described by Mike Cohn in his book "Agile estimating and planning".
Not without significance here are the 3 pillars of the scrum framework and at the same time quite universal mechanisms used to work in a changing environment: transparency, continuous inspection, and adaptation. If we apply them in practice to estimates, it will mean:
- Verifying, as the project progresses and the product and design knowledge increases, whether and how the original estimate changes in relation to the newly acquired knowledge.
- Clear communication of the above to the client.
- Searching for the best solution in relation to what the inspection showed.
Estimate Review
What could this look like in practice?
After the first two or three sprints, once we have gained some knowledge about the project and begin to understand the product better, we review the original estimate.
If it turns out that, for example, functionality X and Y will require more work than we originally assumed, and the pace of our work is lower than expected at this stage, we update the valuation accordingly.
We present the updated valuation clearly and clearly to the client. Together with him, we discuss what can be done to still be able to achieve the goal and meet the conditions of project satisfaction. Perhaps it will not be a problem for the client to increase the financing of the project. It may be necessary to expand the buffer of optional functionalities, and perhaps some functionalities can be simplified, for example.
This approach allows us to efficiently manage project risk and, moreover, quickly identify it and implement countermeasures. This approach also builds the customer's trust in us.
Summary
The appropriate approach to estimates and proper communication of them to the client affects the further implementation of the project, our relationship with the client, and perhaps even our reputation as a company. When estimating an IT project, it is necessary to plan the details properly and limit potential risks as much as possible.
Project Estimation with Railwaymen
We are a Software House, full of specialists engaged in web and mobile software development that deliver innovative solutions for clients, which are based on Ruby on Rails, iOS, and Android technologies.
At Railwaymen, we can together Estimate Your Project within 48 hours!
