Estimating a software development project is probably one of the harshest topics in relationships between customer and company. And in the majority of cases the question is not only about charging the right sum, but also providing realistic expectations management and marketing can rely on. At the same time, estimating a project is the least transparent part of project development. So we decided to start a short series of articles (see part 2 here) to uncover the shades a little.
Why estimate?
Estimate is the most vulnerable element of the whole project development process. Research conducted by The Standish Group in 2015 says that only 29% of software development projects have been assessed correctly. Which basically means that 2 out of 3 projects are going to fail with the estimate provided. So if next time the developer will tell you that he needs a bit more time, don’t be too strict with him, nothing personal here, just statistics.
If estimates are so unreliable, why would we need estimates at all? Agile manifest agrees with this question and generally says that the customer wouldn’t be provided any estimate. So you will know when it’s done, when would actually be done. The only thing you can forecast is what will be done within next 2 weeks.
Such approach sounds pretty tempting for developers, but when we get to life, especially with outsourcing services, the reality is not going to put up with such manifest. Developing a project is always embedded in a much bigger marketing scheme, so one has to provide some estimates. And these some estimates are extremely important for the eventual success of the product.
What is a good estimate?
Okay, now when we all are sure that estimates are a must of any kind of workflow, let’s figure out, what a good estimate is.
“The estimate that was met!” – you might say. Well, you have to hold your horses here. Sure, this kind of estimate is excellent, but it has one huge drawback – it is pretty unrealistic, when it gets down to projects that will take more than a month.
So if to take a realistic approach, good estimate is the one, which has not more than 20% of decline from the final result. As you see, when you get your estimates at the beginning of the project, you should already be ready, that it wouldn’t be met at least by 20%.
Same approach can be put to any creative process, be it house construction or writing a music album. And the earlier you accept the rules of the games, the easier it will be for you to manage the resources with no anger or sentimentality.
At the same time, even with keeping 20% rule in mind, it still can be tricky meeting the estimates set. Let’s have a look at two main pitfalls that are waiting for you here.
Pitfall 1. Underestimating Negative Risks
If you still feel a bit skeptic about people, who don’t meet the deadline, we have a great argument for you – mathematics.
Let’s imagine a case when developer is asked to estimate a project. He has already finished a couple of projects like it, one of those took 8 days, another one 12 days, so he says it will take 10 days. Sounds pretty reasonable, right?
Right now our developer has fallen into a common pitfall – he has ignored probability that something might go wrong. In other words, he added 0 negative risk estimates, which puts the whole estimate under pressure.
Let’s have a look at how the graph would look like with negative risks taken into account.
To make it clearer, we will put it in an accumulative graph, where probability to finish within time range is shown.
As you see, we can tell with 100% certainty that the project will be finished in more than 40 days and the probability that the deadline of 10 days will be met is less than 50%. So basically saying whether the developer will finish the project in time is like tossing a coin.
This in no ways mean that the developer should say that he needs 40 days. We just use this case to make it more explicit that estimates should have risk % to be added. And if you put big pressure on them to be met, this would only mean that the manager would add bigger risk % to protect financial interests.
Pitfall 2. Ignoring Uncertainty Level
Another pitfall, which especially common for Agile projects, is ignoring uncertainty level. Basically, this uncertainty level is why the manifest we were talking previously, refuses to give any estimates.
The problem here is that at the beginning of the project we know about it, its functionality and problems much less than at the end of it. When we are doing estimates, we see only the top of the iceberg.
Sure, good business analysis will let you see a bit more of it, but no analysis will let you know every single detail of it. And in 8 out of 10 cases the final product differs significantly from the one imagined initially.
This is again very common for a creative process. Being ready to change the scope and estimates, especially when working on a big project, would give you some extra cards in playing the project management game.
As you see in the graph, the smaller is uncertainty, the higher the probability to hit the most probable estimate is.
So today we covered two main pitfalls of estimating a project – underestimating negative risks and having high uncertainty level. In our next article we will cover some practical tips of estimating a project. Stay tuned!
Rubyroid Labs was listed as one of the Top Custom Software Development Companies of 2020.
