Estimating a project can be one of the hardest things you do as a technology consultant. Over the years I have done my share of estimation and one thing has become clear to me. Estimation accurately is almost impossible. With lots of experience and some hard knocks, you can accumulate the courage necessary to throw down an estimate. Here’s a few tips that I think might help.
Ask a lot of questions. The first thing you need to do is ask a ton of questions. The only way to get to the bone of the implementation is to understand all the information currently available about the project. Ask the WWWWH (Who, What, When, Where, Why, How) questions.
When you think you have exhausted all the questions in your head, take a walk and forget about the estimation exercise. When you come back you will have more questions, no doubt.
There may very well be details that haven’t been discovered. As the estimator, it is your job to put down a valid estimate. This isn’t the motivation of the sales person, your business lead or the client for that matter. Having a valid estimate creates a framework and a roadmap that the team will follow throughout the project. Without solid questions you are shooting in the dark.
-
Be detailed. It’s impossible to estimate any complex project by taking a high level view and throwing out numbers. You need to break the project down into digestible pieces in order to make sensible estimates that can hold water. For a budgetary estimate, I like to have my work broken down to no larger then 8 hour chunks. Based on this rule it is difficult to miss something entirely or overestimate something by more than 8 hours :)
Most times, the deeper that you think about the work, the more you realize that there are intricacies that you may not have considered when thinking at a high level. You need to find the bottom of the rabbit hole.
-
Assume away risk. One of the most important tools you have as an estimator is the assumption. The assumption is beautiful. It is the way that you politely tell a client no. Assumptions are effectively boundaries that define the border of the project scope. You can say what you will do all day, but that doesn’t tell anyone what you won’t do. Basically there is no good way to make the language around you requirements strong enough to stop a nefarious client from take you for a ride. Assumptions allow you to draw a clear line where the requirement stops.
-
Understand your client. You need to understand the client’s goals, motivation, risk and reward. This is the context that will make you successful in the estimate process and during the delivery phase. Is the client vague? Are they distracted? Are then detail oriented? Anything that will effect the delivery team should be taken into consideration.
To a varied degree this can give you a “gut feel” for how the project will be run and communicated. If there are red flags, then you need to call those out, make assumptions and eliminate the perceived risk.
-
Build an estimate capable of satisfaction. The idea here is to produce an estimate that will make a client happy. Things change over the course of a project - new requirements, shifting priorities, unknown hurdles. When these changes happen, it is important that your estimate is big enough that you can still make the client happy at the end of the day.
-
You are probably thinking, “well, why don’t I just make the estimate huge?”. The trick is to make the estimate big enough to accommodate the unknown but also fit into a logical and economical budget number. If you strike this balance it will allow the project team to manage the project to a happy conclusion because your estimates were large enough to make the client happy. Too small an estimate and there is no room for management.