As a consulting company, we review a lot of potential projects. How do we find those that are a good match for our expertise, culture? The short answer is: it takes a lot of work. One piece of this process is estimating the effort (and therefore time and cost) required to complete a project. This blog series dicusses why good estimates are important, what to consider when estimating, and how to estimate.
In this first post, we’ll talk why careful project estimating is important. For more on the nitty-gritty of how to do high-level project scoping, refer to the second blog post in this series: The Art of Estimating. Finally, the third post in this series, Let’s Practice Project Estimating encourages you to apply your new-found knowledge!
Estimating potential projects is a balancing act: on one side of the tightrope, we want to provide an accurate estimate of how long we think it might take; on the other side, we want our estimate to be aggressive enough to be comparable to competitors. We need good high-level estimates so that we can gain and retain client work. When our estimates are off, projects go over-budget and over-time. Better estimates means happy clients with realistic expectations, and when we can meet those expectations, we get repeat customers!
So, how do we take a broad set of features or a description of someone’s desired application, and estimate how long it will take for us to build? It’s not a simple process. Honestly, a lot of it comes down to having experience solving a variety of problems in software. If you’ve done it before, you have a good idea of how long it might take. Thinking critically about the potential project, anticipating risks, identifying hidden work early, and recognizing red flags go a long way. Even though a lot of estimating comes from your gut, there are still some things you can do to be a little more exact in deciding the scope of a project. We’ll talk about these next.
As an estimator, I receive a wide range of requests. These range from formal requests for proposals (RFPs), complete with detailed feature specifications and timeline requirements, to scanned notebook pages of someone’s startup idea. Depending on what kind of request and documentation I receive, I’ll estimate it differently. More on that, below.
When first beginning to estimate potential projects, you might have some questions around this. Besides the obvious “How do I estimate?” (which we’ll get to, below), some questions I’ve encountered include the following:
Usually we don’t have access to the potential client to ask future questions. Talking to the sales team about those questions can be beneficial. They might have more information they can provide. If nothing else, having asked sales those questions gives them the chance to talk to the client in future conversations.
The length of time I spend estimating correlates nicely with how precise I need to be in my estimate. Remember, when we’re estimating a potential project, we haven’t signed any contracts yet. While we need to do our due diligence to make it accurate, there’s a balance between time spent and how precise that estimate needs to be. There’s a big difference in time spent between formulating a “ballpark” estimate and a thorough one. In general, though, I spend up to an hour for most estimates, and 2 or 3 for the most detailed and thorough analysis.
TL;DR: It depends on the type of proposal (formal RFP vs. informal). Formal RFPs need the most complete estimating.
Some estimate requests require more detail than others. Sometimes, at the beginning of a relationship, a high-level “less than 3 months, 3 months, 6 months” estimate can be enough to know whether to continue moving forward. Formal requests for proposals require the most effort to estimate. RFPs generally have more detailed requirements, often include wireframes, and usually have time or budget constraints. The question to answer in RFPs is frequently “can we do all of this in the time/budget allotted?” The answer is almost always a “yes, if…”, and so the bulk of the work becomes identifying risky work, features to de-prioritize, and necessary work that’s been left unidentified. Because we’re consultants, not just contractors, highlighting these kinds of things with our clients ultimately provides them with a better product.
When reviewing provided documentation, I’m not just thinking about how long it might take to build what’s being presented. I’m also jotting down notes about:
- red flags
- risky feature requests or requirements
- requests or statements that are unclear or confusing
- hidden work (things that I think will be required but aren’t documented)
What are red flags in a request? These can be things that, as a developer, I see as unethical, impractical, or poorly understood by the potential client. It could be a mismatch in technology or culture fit. A risky feature request can be something that might seem easy, but are really difficult. It could also be a feature that may not be feasible inside of the budget or time constraints. Confusing requirements and feature descriptions are common in many requests. When you’ve come up with a great idea, it’s easy to forget that everyone else doesn’t know all the details in your head! Hidden work can be a variety of things: forgotten admin panels to manage users or content, or a server, database, and API for a mobile app that needs to store and retrieve data.
Other considerations include things like the time required for submission to the Apple AppStore for iOS apps. This is especially important when estimating with a time constraint.
Whew! That’s a lot to think about! There are a lot of variables that affect how I estimate: what kind of documentation I’ve been provided, what things might be missing or understated in that documentation, and how precise my estimate needs to be. The second post in this series (The Art of Estimating) dives into the details of how to translate a vague feature set into an estimate you can have confidence in. See you there!