A brief read about how we approach project estimations at Think201
Let’s begin by basics first
What is Project Estimation?
It’s a process of estimating the cost for the set of activities that are required to be done in order to complete the project. Project estimations give an idea of the budget to its stakeholders.
What all we consider while doing a Project Estimation?
A common notion about “project estimations” is to consider development hours which is very wrong. It covers much more than that.
To think estimations are only for development hours is to think only of construction charges of building a home & nothing else.
Project estimations include estimating time & cost for activities that span from the beginning of the project till its end i.e, which is until it’s made live to end-users. To elaborate, it includes time & cost to perform
- Product Feature Scoping
- Product Understanding via brainstorming sessions
- Product Documentation
- Product Architecture
- Product Design
- Research & Tinkering
- Product Development
- Quality Assurance
- Server Set up & Deployment
- Migration of old data (if applicable)
All these activities are very important and are time-consuming activities. Omitting any of these will result in improper project estimations.
We don’t guesstimate, we estimate
We care & respect Founder’s time & their interest to work with us. That’s the reason we never do rough estimations. There are instances where we have denied a quick turnaround on estimations since it’s merely impossible to quickly estimate without knowing what we are building.
We approach project estimations as an internal workshop that would last for 3–4 hrs involving people across different roles. Each one of them brings their expertise & perspectives in analyzing the hours required to build a set of features thereby taking out bias & assumptions.
Estimations in terms of “Feature Hours”
Feature hours means the total number of hours that are required to understand, design, develop & test a feature thereby covering all aspects of estimation for a feature.
We don’t bill for people involved rather we bill for the time it’s required to build the feature across various phases
How often do we hit the bull’s eye with estimations?
Estimations by the name itself say that it’s a prediction. However, we try to take the uncertainty out by referring to our data from Trackivity.
Trackivity is a product that our team uses to estimate & plan their tasks while working. This gives us a very clear indication of hours that is required to design/develop/test a feature/ module.
We have a reference to this data which combined with our expertise in the field to surely say, how many hours do we need to build your product. That is how we make it fair for Founders & the team who works on it.
With a data-backed approach combined with people from different streams involved, we seldom make a mistake w.r.t estimations. That’s how we have never overshot our estimations unless there are new inclusions on the way of product development.
Sounds interesting? Let’s connect to breathe life into your idea: here