Project Delays? Here is Why Your Estimates Don’t Work
Almost every software development project starts with the questions: “How long will this take? How much is this going to cost? How many people do we need to get this done?” These are all variations of the same question: “How much effort will this cost in terms of time and money?”
And the most common replies are either “we don’t know” or “let us estimate first”. The problem is that nobody likes these answers. Stakeholders don’t like the first reply because even though they need an answer, they don’t have the knowledge to give it themselves. Technical teams don’t like the second reply because estimates take a lot of time and are often too rough to be accurate.
Why estimates don’t work
Traditionally, a project manager compiles estimates on a software project and shows them to the boss who looks over and sets the date for delivering the project. Then there is a team meeting where the plan is presented with all honors and celebrations, and everyone comes back to work expecting they’ll meet the stated deadline.
And in most cases, the deadline is missed… Project managers blame lazy developers. Developers blame unrealistic estimates of project managers. In the worst case scenario, most of the team will quit, and the final deliverable will be filled with bugs.
Unfortunately, this happens over and over again. And there are four reasons why estimates fail.
#1. Focusing on a best-case scenario
When a project manager asks developers for estimates, they use their experience, knowledge and depending on how they are familiar with the project, make an estimate. It’s then used by the project manager to determine how long the project will take. And in most cases, these are the best case scenarios. And what if the worst case scenario kicks in?
The problem is that most people are too optimistic when it comes to estimating how long something will take. Another problem is not including “thinking” time in estimates – e.g. developers often estimate the time necessary to write the code and forget about the time needed to think about it. If it takes 30 minutes to write a feature and 3 hours to think about how it will look like, you will be way off schedule if you haven’t included “thinking” time in it.
#2. Shifting the scope
A developer estimates a certain period of time for a certain task. And if the project manager adds new stuff, nobody can hold the developer to the original estimate because any new change means that the estimate will also change.
And though it sounds logical, this concept is often ignored, so no wonder the final date is wrong. The golden rule to remember: adding stuff makes the job take longer. Period.
#3. Not taking into account how features interact within the system
Developers often forget that features don’t exist in a vacuum. They interact with other features and impact the whole system. So adding, replacing, changing or fixing one feature will inevitably result in more work and more time spent than you expected.
#4. Ignoring the artistic nature of programming
Even if you ask 10 developers to implement a certain function, you’ll end up with 10 different approaches. There are certain tips and tricks that vary from person to person. This uniqueness is often ignored as well as the fact that programming is more art than science. And art doesn’t follow the schedule.
