Sunday, June 10, 2007

What can be evidence for "Estimating Rationale" in Project Planning?

What can be documented evidence for "estimation rationale?"

Hey, I asked a Sr. Engineer for an estimate and he told me. Isn't that rational?


It may be rational, but it isn't evidence of estimating "rationale." That darn "e!" changes everything. I hate that!!

Estimation rationale is a way to explain how you and your team came up with an estimate. Did you use any specific estimating process? If so, what were its outputs? Did you count reports, screens, features, functions points, or lines of code? If so, what was the output of that exercise? If you’re in an “agile” world, did you estimate a number of releases and iterations and allocate the high-priority features you planned on delivering during each one?

I always ask myself “why does the model want to know this?” when I’m stuck trying to figure out why a practice was put into the CMMI. In this case, they seem to have been looking for evidence that an engineer didn’t just “guess” at what the estimate would be – but went through some process to validate it. This is process is the“rational.”

So, how did you validate your last estimate? The output of that work is your evidence. Or . . . did you just guess?




www.broadswordsolutions.com

2 comments:

Muhammad Ali Inayat said...

hi
"So, how did you validate your last estimate? The output of that work is your evidence. Or . . . did you just guess?"

Thats the point if the company is ONLY relaying on "expert opinion" then what can be the OE.

Anonymous said...

On our last appraisal, for PP SP 1.4: “Estimate the project effort and cost for work products and tasks based on estimation rationale," we showed the following pieces of written data:

1. Project planning checklist stating we would use prior year’s metrics.

2. The actual # Lines of code from the prior year for the models.

3. The actual # hours from the prior year for the same work.

4. Written paragraphs describing the understanding of the current year’s work activities.

5. The planned # Lines of code for the current year’s models.

6. The planned # hours for the current year’s effort.

7. Work Assignment Sheets, with description of work to be performed, specific issues to be addressed, assignee, and # hours allotted.

8. Planned costs computed for those # Hours (in PS8).

The majority of my appraisal team wanted to rate PP SP 1.4 “Partially Implemented” because they felt we were missing one critical element: how we took actuals from the prior year and translated those into plans for the current year (e.g., with a multiplier, due to complexity differences and/or team experience differences).
I felt that the absence of that piece of written data was not sufficient to prevent us from attaining the larger Goal.
What do you think?