Planning your Estimation

A project can succeed or fail for a variety of very well documented reasons. I want to touch upon one reason i think impacts projects before anything else does -Estimates! Rather than write on detail on "How to Estimate" (Plan-Do-Check-Close is always a good philosophy), I want to share some tips that are helpful

• Make sure you understand the scope - The way i like to look at this is - Can you describe the scope in a short paragraph without the use of a "But" or "If" or an assumption?If you cant, there is a good chance your estimates will be incorrect.
• Estimates are best done in iterations-There is no such thing as getting an estimate right the first time you do it. A good estimate is arrived at by setting a base line and fine tuning it to a place where it provides maximum comfort to all stakeholders. Bad corollary but effective - An estimate is like a chef cooking curry, keep tasting it to where it seems just right. :)
• Estimate (Total) = Estimate (Core Work) + Estimate (Non Core work). Meetings, Mail Checks, Reviews, Communication, documentation and many more are non Core Work. Remember the formula and use it as a philosophy. A good figure to go by is that generally 80% of estimate should be core work.
• Know your Buffers - Risk Buffers, Expected Slippage Buffer , Scope Creeps , Expected delays, Uncertainity all need to get factored here. What these figures need to be? Get an experienced hand to guide you and go by gut feel.
• Budget enough time for estimation - one ballpark i like to use myself is - 50% core estimation work vs 50% review and re-work on the estimates. At times you do not have the luxury of so much time. The ballpark still holds - find time for a review.
• Have specialists for their role - ie an Architect, a developer, a tester to take care of their items. No substitute or tip here. Must do activity.
• Technique - While choosing the technique to do your estimation, try and choose 2 techniques and run them parallelly. In an ideal case , 1 should be a bottom up approach and the other should be a top down. Arriving at independent figures will give you 2 perspectives and if the 2 dont align well with each other, you know something is broke. If time and expertise dictates that you are not able to use formalized techniques like wide band delphi , function point analysis then use your home grown wbs but still do the validation between bottom-up and top-down. You'll be glad you do this.
• Another biggie is to tune the estimates according to a high level plan. Mostly i have seen the estimate to be fixed and the plan is created to match the estimate. This exercises is dangerous as it can over commit on delivery expectations. Good planners will create an estimate and a plan and start iterating (Modifying) on either to achieve the right balance. Balancing a plan, schedule and estimates is a key exercise in estimation.
• In your review setup, you need to have some distinct type of people. They are - People who have executed similar work themselves , People who are probable to execute the project when it comes to you and People who prepared the estimates. Split up the review into 2 parts - Firstly, Validating the estimation exercise from an "technical" perspective and secondly, validating whether the scope of estimate coverage includes items like project risks, activities that are non functional in nature.
• For the review, be prepared to create a pivot chart your estimates. This will give enough flexibility to the reviewers to slice and dice the estimates to review it properly according to their experience. They can utilize it to look at phase wise distribution amongst many other things. This pivot can also be useful at the planning stage. look at this example

Key Figures removed for IPR protection.