Before making a deal, everyone prefers to know all the details of future cooperation. One of the first questions a client asks the developing company is a project cost estimate and the time necessary for completion one or the other job. The issue can be tricky since it’s not easy to evaluate work instantly.
Now we’ll try to describe the time estimate process in our company.
How the Evaluation Process Starts
First, the developer divides the project into smaller parts. Each issue gets evaluated as to how much time it might take to finish it according to the specialist’s common sense and experience in performing previous works. Now we have a rough estimate which is basically an assumption. We can’t rely on it solely if we don’t want to disappoint the client in the end. The probability of meeting this deadline is low since we don’t consider any risks that can interfere with the work.
What Can Slow Down a Project
To create a more exact deadline, we use Jira software, our internal statistics, and probability theory taking into account the most common risks that may arise. The principal factors that usually influence a deadline include an error in the original estimate, a growth of the requirements, an effect of productivity variance and communication expenses. The list is not exhaustive.
Our Approach to the Estimation
We start with creation Jira tasks for all the issues. After that, we download them in the form of a table and put the anticipated time frame in front of each part. That’s the initial illustration of the project we are going to work with. Then the data goes into a project simulator that runs the project 500 times. It gives us an opportunity to calculate how much time should we add to the primary estimate assessing all the risks by the law of probability.
After the calculation of various possible scenarios, we get a table of data presented below.
It shows the probability of completing the project in a set amount of time.
Let’s see the diagram based on the simulation results.
The vertical axis demonstrates the number of instances run by the simulator. The horizontal axis shows the number of hours needed for completion the project given that some or all of the adverse events occurred during 500 runs of the simulation. The blue area represents the finished project.
For a better understanding of the subject illustrated in the diagram, let’s draw an imaginary vertical line that divides the blue area into two parts with an area equal to each other. On the x-axis, we’ll get the number of hours required to complete the project with 50% probability. However, 50% is not enough. To be confident that we’ll be able to get the job done by a specific time, we need to have at least 95%. From the figure, we can see that this probability corresponds with 197.44 mark on the scale. So, this is the number of hours we give to the client.
As you can see, our approach to establishing the timeframe for the completion of each project is scientifically well-founded and reliable. We don’t want to give our customers false expectations saying that we can do the job faster. In the long run, it would only disappoint them and destroy trust. There are different situations, but it’s always better not to sacrifice quality for speed. Everything is up to you. Whatever the decision is, we will always be happy to provide good services in a reasonable amount of time.