When working on a new project, a lot of senior executives and managers often ask about its duration i.e. how long will this take and when will it be complete?
THis question starts from the top and goes down to the bottom. It goes throughout the organizational and team hierarchy to the engineers which are responsible for creating the software product before the final estimate is made. That estimate is hence sent back up to the executives, managers, management, and shareholders.
Shareholders usually end up treating it like a development schedule of sorts. THey often use it to set a rigid deadline. When the project is over, the estimate is often quite a lot inaccurate in wild terms. The team hence embarks on a self-reflection journey to find out what went wrong.
Why do companies underestimate the duration of projects?
Each team working on a new product runs into this issue at some point in the product development process. Let us have a look at why does it happen quite frequently.
Most companies are usually naive in most situations
A problem with the initial estimate is they are usually complete when management or employees (or both) know the least of the project, its trajectory, and any barriers it can face.
It is like trying to make an estimate of how long a Coconut palm tree will reach its full height when its only in the seedling phase. Things which cannot be prediucted can affect the tree’s growth especially drought, disease, pests, war etc.
Hence it is best to use that estimate as a target fluid in nature which can (and must) change when the new information about that very project becomes available.
Hopeless and pointless optimism
ASk a child what they want to be when they grow up, they will tell you about their dream job. Everyone plans for the best case scenario all the time because if they plan for the worst, they are ostracized for being excessively pessimistic. Software engineers are no less. They are often accurate at estimate the best case scenario for how long these projects must take.
The problem lies in the fact that unforeseen issues add more issues to the development time and schedule. They are not usually taken into consideration during the initial project estimate. SOme of those issues are:
- Bugs and Glitches.
- Dependendencies on 3rd Parties’ schedules.
- Changes in project requirements.
- Researching on new technologies.
- Learning new technologies.
- Team member turnover.
- Any holidays or employees on vacations (or both).
- New technology development.
Ways of making software development estimates more accurately
It is hard to make an accurate estimate. A lot are trying to predict the future with limited information. A reliable formula is not present. Then again some things can be followed nicely to get a nice and close estimate with a degree of accuracy:
Improving the product discovery time will help define the issue properly
One of the best ways of improving the accuracy of development timelines is spending more time in product discovery. Apart from time, valuable time through an architecture sprint or a comprehensive discovery can work out quite well.
A key rule of making this work is understanding and testing the perceived issue against technology restraints plus user feedback.
For identifying problems, interviewing existing and prospective users is key pus conducting proper research. Examining what exists in the market helps provide a good view of the existing products and services. Various factors need consideration to create solutions, especially:
- Adding market opportunities.
- Expense to create solutions.
- The present and prospective risks.
- Time to market.
- Value.
It isn’t easy for engineering teams to assess concepts objectively. Teams tend to love their concepts because they made them from their ideas. An outside perspective is always needed to help understand what to create.
Using High, Middle and Low
This tactic according to experts from best app development company in Dubai is useful for bringing best-case, worst-case, and most likely scenarios based estimates. It helps in the following ways:
- It gets them thinking actively about issues that can literally derail a project.
- It helps them consider the likelihood of how those things can occur.
- When the project is complete, teams can revisit the estimates to observe the most accurate one. It provides hard data to use for the next estimate.
Doubling the estimate
Development teams should come up with a best case estimate. Then they should multiply it by two to take into account all setbacks. If the project has a lot of features or technologies which teams or vendors were unable to deal with, multiply that by three. This way of estimation helps paint the picture for how long the project will actually take.
These ways of estimation can at least help paint an accurate picture of how long a software project can take. It is better than inaccurate guesses.
