Estimating a new project is hard and time consuming. Why? Because when you start a new project, you are at the point of maximum ignorance. In most cases there is a solid idea, but the required functionality is ambiguous.
The business is depending on you — the engineering team — to identify a high-level timeline.
I estimate a lot of projects like this every year. Here are a things I do to cope with that ignorance and ambiguity.
1. Select the Right Magnitude
Begin by deciding a uniform level of precision for your estimates. If you think the project is going to take years, then your estimates should be in weeks. If you are guessing months, your estimates should be in days. And if you think the project is going to take weeks, you should estimate in hours.
2. During Decomposition, Avoid Focusing on the Technology
After you have defined the magnitude of your estimates, it’s time to decompose the project into smaller components that can be estimated. I try to focus my decomposition on the things that need to be implemented rather than the technology or libraries that will be used. For example, if we are building a web application that needs logins, I focus the component I am estimating on the action of user authentication (login, forgot password, etc.) instead of thinking about the newest gem or jar that supports the functionality.
When I fall into the trap of thinking about the exact technology used, my mind immediately starts trying to solve the problem. At this point you don’t want to solve the problem — it will take too long and not improve your estimate. The goal of estimating is identifying how much time is needed to solve the problem. In this case, I feel confident that I can implement and solve any problems associated with the action of user authentication in a few days.
3. Define Assumptions
Estimating unknowns and what-ifs is difficult, but that doesn’t mean you are unable to estimate. Instead, you should scope the problem with assumptions and estimate based on the assumptions holding true. For example, if your new application is going to leverage an existing proprietary math library to perform core functionality, you have a difficult (if not impossible) task to estimate without thoroughly researching that library and gaining experience using it. However, if you make some sane assumptions (written in C, flat API, tested logic) then you can make an educated estimate.
When I make assumptions, I make sure that I am transparent and clear about them. I also focus on them during the first phases of the project to mitigate project risk.
4. Define Risk with Ranges & Buffer Accordingly
Another way to handle unknowns and what-ifs is to properly account for risk with a buffer estimate. For each component that you estimate, make two estimates — the first estimate for how long you think something should take, and the second for how long it could take if you encounter problems.
Most components will have a small ranges (little risk), but some components will have large ranges (big risk). With those risky components, defining the risk and putting your arms around the size of the problem is much easier than allowing yourself to get pulled into solving the problem. Remember, you are estimating not solving.
You can learn more about creating a responsible project buffer in Making Better Range Estimates.
5. Validate with Historic Data
When you have completed your estimate, compare the actual implementation time and cost from similar projects to the one you just estimated. Use this past history to ask and justify why the new project will take more or less time.
Our home page includes a few high-level costs for the types of projects that we specialize in.