I’ve been doing a lot of cost estimations lately for the development effort. Being a developer, it does not lie in my comfort zone as there is always an anxiety of underestimating. After some practice, I realized that there isn’t any rocket science here.
Points to consider while estimating:
- Figure out the problem scope first. It’s important to analyze how big the problem is or what the expectations are.
- Figure out the budget scope. The feeling generally comes with the problem statement. Being aware of the expected cost directly changes the scope.
- In case of doubt, provide alternatives. Propose different cost estimates based on the value they’ll add to the business. Reduce development scope and propose low-cost solutions. Increase the scope and propose long-term solutions. Very similar to choosing one of weekly/monthly/yearly subscription pack. Mention pros and cons in each.
- Task breakdown and the 4-hour theory. Break down the requirements and proposed solution into chunks. For each subtask, estimate a high-level effort. If something will take more than 4 hours, that means it can be further broken down.
- Don’t always need to mention the complete breakdown. While proposing, mention module and add it’s effort/cost (a module may consist of one or more tasks). But do save the breakdown somewhere else in case later asked for or can be used while execution.
- Communicate if there is an abstraction or it is just a guesstimate. Be clear that upon some more insights, and after looking a bit deeper, a more precise estimate can be provided.
- Follow a pattern. Varies from project to project, but having a basic structure in place will always help to put down the estimates faster.
We’re always improving our processes. Tuned in to stay updated.