If you haven't read it already, there is a lot of really good meat in the first article on this topic by Seth Brown. Seth does an excellent job of digesting our process of working with our clients during the decomposition of a project to figure out just how much this baby is gonna cost.
Estimating
One thing that has evolved since the writing of Seth's article, is the spreadsheet that we use for our work breakdown, and the exact method in which we go about estimating the various deliverables. The spreadsheet is full of notes on how we go about our various estimates, and the things what we calculate automatically.
First we have at least three developers who are going to be working on the project conduct a blind estimation line by line with white text on a white background and then do a reveal all at once. During the reveal, if we find that there ends up being large discrepancies in the estimates, we talk about the assumptions each developer made in order to make sure we're all on the same page with what is expected for said deliverable and give them a chance to adjust their estimates given any new information. We then average these as the total estimated developer hours.
There is also an added "pm factor" for our project manager which is a .25 multiplier. This multiplier is based on Lullabot's historic data for our projects where we've found that project managers end up spending about one quarter of the time developers spend on a project overall.
Our updated spreadsheet also introduces a concept of a risk or uncertainty factor which is helpful in calling out the unknown aspects of a project. The higher the risk, the more unknown that element of the project is. Measuring risk also helps measure the difference between a fixed-bid VS a time and materials approach to the project. Risk is measured on a scale from 0-5 and we calculate additional developer hours by taking the sum of the developer average plus the pm factor and multiply by the risk rating. Finally we multiply again by point one (=sum(Average+PM Factor)URating.1). We're basically asking our developers how uncertain they are about their estimates and why. It's usually because of some unknown factors, and we try to determine if these factors are something that the client can help us aleviate. If so we go back to make sure that expectations are clearer and give our developers the opportunity to reduce the risk and adjust their estimates. But sometimes it's a factor that is simply not controllable and if the risk remains high it increases the overall estimated hours.
Resourcing
We've also added a new sheet which helps us to figure out what resources we need on the project in order to accomplish the estimated deliverables and to help us to align our resources with the timeline of the project and the estimated amount of work. This helps our project mangers to get an idea of which deliverables they should schedule for each sprint. For instance, if they know that they have 80 man hours during Sprint 1, they also know that they can schedule X amount of deliverables for that first sprint based on how many hours were estimated.
This also gives us a chance to think about dates going forward and account for any scheduled vacation times for the developers who are on the project and holidays can also be factored into the timeline. In the case of a fixed bid project, we can either add resources or if we have no more available resources, advise the client that we'll need to cut scope in order to meet their budget.
We continue to revise our approach to this process as we find better ways of trying to come up with more accurate estimates in order to meet our deadlines, budgets and to set client expectations appropriately. So far our latest version feels like the most accurate we've gotten to date, but we'd love to hear what you think about it! How has project estimation changed for you?