I would like to create common checklist for project estimation in my organization. The idea behind is to make sure that you have taken into account different aspects (ie. lack of knowledge of given technology, people leaves, 3rd dependencies, complex UI, etc.) in the estimates. I would like to find out if someone has been already verifying estimates against such help questions. If so, how detailed they are, what kind of types you are using? Do you find them useful?
-
You might want to do planning poker in your estimations, than all questions will rise automatically: pm.stackexchange.com/questions/1076/…– KennethvrCommented May 19, 2011 at 13:30
-
1Thanks for reply! But generally I'm thinking about doing kind of sanity check of estimates - verification that you haven't forgotten about something during estimation– Tomek DabrowskiCommented May 19, 2011 at 13:45
6 Answers
What you're describing sounds more like a list of potential risks and lessons learned than simply estimating. So my advice would be to go back through past projects and identify those things that caused the most trouble, and make list of those.
Start with that list, and then from here on out, keeping adding as you identify new risks on projects and learn new lessons.
-
Thanks! I agree with you that we should start with lesson learned for such checklist. Just wondering if there are maybe some common things ie. Have you estimated writing a end user documentation? Have you estimated writing automated tests? etc. Commented May 20, 2011 at 9:33
You can use Taxonomy Based Risk Identification from SEI. Just get rid of parts you don't need. It is also includes questionnaire.
Steve McConnell has an Estimate Sanity Check (Appendix A) in his book Software Estimation: Demystifying the Black Art. This is, like it says, a sanity check, not necessarily a checklist of considerations.
Some considerations I have personally encountered (in no particular order):
Team (size, longevity, experience);
Project (scale, clarity of requirements, domain[1], repeat of similar project, risks);
Tools (maturity, team experience with, complexity, availability of support);
Organization (overhead[2], management support, budget)
[1] The particular domain of a project may change effort (i.e. - financial industry vs. gaming)
[2] Organizational overhead can greatly influence things like bringing in new team members (i.e. - background checks, drug tests, security, new PC, etc.)
Use the work-breakdown-structure as a basic list of items that need to be estimated.
Then track estimates versus actuals to build up a database over time of parameters that affect the estimate.
A lot of things that go into an estimate is based on expert analysis and judgment. It comes down to methodology and technique versus those tangible actions against which you can have a checklist.
Your estimating/planning process and procedures can easily have a checklist to ensure that all steps have been taken, controls have been met, approvals obtained, etc. So to construct the checklist, I would examine the process and procedures and capture the wickets over which you have to jump.
The examples you cited above are, in my judgment, part of the analysis and expert judgment and opinion. I cannot see how to break down 'thinking' and 'opining' into checklist items. To ensure that an estimate is comprehensive and credible, I might start with a basis of estimate template that must be completed as part of the estimation process. At the very least, the BoE can be critically examined to try to ascertain the quality of the estimate.
before you ask questions, remember to check if they understand the concept of estimating. Are you asking for effort or duration? Don't assume people know how to estimate, have them break the task down - even if it's just in their minds - and add up the time for each task. Offer to work through it with them.
I know this is very basic, but often estimates don't work because assumptions are not opened up in the process.