Are you involved in your company’s project estimation process? If so, let’s pretend. Let’s pretend that your company has internal constraints which makes estimating rather difficult. For example, let’s say you were required to completed all of your 2008 estimates towards the end of 2007 despite the fact that very few requirements were known. Don’t get me wrong. There were a few requirements but they were very high-level or what I would equate to a vision document or merely a great idea someone thought up while taking their morning shower. Of course, no one should expect these estimates to be all that accurate, but just for fun, let’s pretend that some felt they would be good enough to use as a basis to determine the entire budget for 2008. Kind of scary, eh? Well, I’m familiar with such a process and it is really scary and frustrating and, in my opinion, a tough way to end and start a year. You do learn to deal and make the best of it though.

It goes without saying but estimation is an art. It is hard enough if you have all relevant information at your fingertips. The thing is we rarely do have everything we need. Now, I recognize the provide example is a little to the extreme, but it happens. Believe me, it happens. Again, you do learn to deal and make the best of it though. But what if one wanted to improve on the process summarized above? What could be done?

I think the first step is determine the key factors in providing a good estimate which I believe included the following:

• You Need Good Requirements: Good requirements have the greatest impact on an estimate. As requirements become more complete and detailed, estimates become more accurate and our confidence increases. Period.
• You Need An Appropriate Estimator: Estimators should be chosen based on their understanding of the requirements, their knowledge of technology and possible solutions and their past estimating experience. The decision of whom should estimate one’s projects should not be taken lightly.
• You Need To Know The Implementer: To provide a good estimate, it isn’t really necessary to know who will be performing the work, but since no two developers have the same skill set or experience, knowledge of the implementer can help firm up an estimate considerably. If nothing else, you need to know the candidate’s assumed skill set and domain knowledge.

It should be noted that we often think that timeline and/or budget have an affect on our estimates. This is only true because these factors affect scope, which in turn affect requirements, which are ultimately reflected in the estimate.

Once the key factors are identified (maybe there’s more than listed above), a better process needs to be defined. Assuming the company absolutely has to continue estimating and budgeting for the upcoming year prior to having solid requirements, I would suggest breaking the estimation process into three stages in order to continually firm up one’s numbers as additional information is provided:

• SWAG: This high-level estimate is based on the limited requirements offered in the project request. Since this estimate is typically provided by management, and is based on few requirements, it should come along with a fairly low confidence level. Unfortunately, the allocated budget is tied to these estimates. Since none of individual estimates will be accurate, the best case scenario is to end up with estimates balancing themselves out. In other words, for every over-estimated effort there will an under-estimated effort. If the majority of efforts are under-estimate, you are screwed. If the majority are over-estimated, you are bound to have some awesome launch parties.
• Detailed Estimate: This estimate can be produced once detailed requirements are offered. This requirements would come in the form of a BRD or FSD. Who produces this estimate? People with knowledge of the product and the technologies who will hopefully be involved with the project until it is released. This estimate becomes the foundation of the project plan and is the basis of all staffing requests.
• Developer Validation: Once development assignments are distributed, each developer will validate the provided estimate against his/her associated tasks. Adjustments to the project plan and staff plan will be made if necessary.

In theory, one should expect estimates to change as scope or staff fluctuates — if we follow the steps above.

In no way is this high-level plan a silver bullet. It isn’t necessarily realistic for all shops as I, for one, can’t remember the last time I was asked to estimate a project AFTER I received firmed up requirements and I can’t think of a single case where scope didn’t change between a project’s inception and its end. I guess that’s why estimation is an art. You must leverage whatever process you currently have in place, search hard for few facts and then provide your best guestimate all the while knowing that things may very well change tomorrow. I do believe if one respects the key factors and overall process above, there’s a better chance of success than if these core ideas are disregarded.

Best of luck with your next estimate. By the way, what did I miss?