It's a fact of life when working for a service based software company that clients want to know how much something will cost. As an estimator there are a number of other unfortunate realities.
- You will rarely have all the information you need to make an accurate estimate
- Your will often asked to provide "realistic estimations" however these estimates will be judged against a randomly invented figure (often dreamt up by a BDM or similarly unqualified person based on what they think the client will pay)
- You will often be asked for a ballpark figure - then held to ransom by it 2 months later
There are only 7 things you need to remember.
- Know What You're Estimating (and what you're not) - perhaps the most common mistake in all estimates is the assumption that someone else has covered the areas you haven't. I can't state enough the importance of communication. Talk to the person you are providing the estimate for. Talk to others providing estimates for the same work. Don't assume anyone else knows what they are doing. Find out whether you are only estimating implementation effort? Who is going to include estimates for analysis, design, meetings, testing, deployment, support, project management, documentation, licensing, hosting. Talk, talk, ask, ask, talk some more...
- Break it Down - it's impossible to estimate or justify an estimate without breaking it down into meaningful chunks. And it is crucial you can justify your estimates; you can't simply say "well I think the whole project will take 20 days" without saying why. Where possible the way you break up the estimate should be as meaningful to your client as possible (while you may not show the details to all clients, if asked for a full justification clients will better understand your estimates if they are broken down in a language they comprehend). Every estimation is different, but here are some common ways to break down implementation effort.
- By End User Elements - for example, providing costs for each user interface, report, web service interface...
- By Use Cases - breaking estimates down by use case is especially useful for producing high level estimates. You will probably have sub-estimates under each one to provide more details
- By Functional Areas - similar to above but not everyone uses use cases
- Horizontally Across Tiers - I'm not a big fan of doing this but some projects lend themselves to breaking the work down by layers. For example. data layer, business layer, services, user interfaces etc. This is sometimes easier to estimate especially if different people are going to be involved at different layers. However, the main reason I don't like this is because it is generally meaningless to your clients. They have no way of knowing how much a particular business feature will cost. This is particularly important when you are working through the estimates with a client and negotiating scope.
- Nothing Takes Less Than Half a Day - for anything but the most trivial of estimates nothing should be estimated at less than half a day. If you find yourself at this level of detail then consider combining items into a single, larger, estimate.
- State Your Assumptions - it sounds obvious but it is often forgotten. This is particularly important when you have limited information but still need to provide an estimate. In my experience, assuming the best but expecting the worst is a good approach. Primarily because, if you assume the best, your estimates will be lower and more attractive to your clients. If things change and get more complicated you have covered yourself and can explain this to your client.
- Estimate for the Masses - unless you know you are going to do the work you should estimate the effort based on how long an intermediate level resource would take. This is especially true if you are a super-star - the person doing the work may not be so don't set them up to fail.
- The Law of Optimism - this law states there is an inverse relationship between the experience of an estimator and their level of optimism. Typically more junior estimators will be overly optimistic - they can be cocky or simply haven't experienced enough "estimations gone bad" to know that things invariably don't go as planned. More experienced developers know to expected the unexpected. As such they are more likely to provide conservative estimates.
- Compare - comparing your estimates against other similar projects is essential. This is particularly relevant when you look at your estimate as a whole. When you last implemented MCRM and a public web site, how much did it cost - are you in the right ballpark.
So that's it - some commonsense tips for estimating.