I was engaged in a pre-sales activity and one of the clients gave me few functional specs and requirement docs and asked me to come up with an estimate for an user guide.
That is when I began to look at different tools and methods used in estimating, and I explored the following options to provided estimates:
· Based on SWAG (scientific wild-ass guess)
· Based on previous (historical) data for similar kind of project
· Based on industry standard
SWAGing it Out
I went into a huddle with my team and asked them to take a guess and come up with an effort time for the project. Every one had different values; Team Member A gave 200 hrs, Team Member B gave 250 hrs, and Team Member C gave 215 hrs, and so on. I was in a fix, whom to consider? Each team member's expertise varied, one was good in information gathering, and the other in outlining the framework, and so on.
I took the approach of looking back at what we have accomplished (historic data), and come up with the number for the current set of requirements.
History shows that we made it; if we pursue, we can do it this time too
The challenge was to dig deep and pull out the numbers (effort time) from the documentation project we had undertaken earlier. When I began to do this, I found that for few of the projects I could get some values and for most I could not, because no effort was made in capturing the effort time for the entire life cycle.
Back to Square One, confidence on the estimate was low. Looking at the industry standard was the other option that was left with me to come up with an estimate.
How others estimate? What is the Ball Park? Can we apply it?
I assumed if I start googling out, I could come up with the numbers used by the industry for estimating. When I did that, I had the following questions:
· How many pages, one can produce in a day?
· How scope changes was handled?
· How complex was the project?
· How many new topics and updates were accomplished?
· What was the strength and experience level of the team members?
And so on.
The numbers for each scenario (complexity, audience, domain, skill, and so on) were different; however, I arrived at project estimates sans confidence or comfort.
There is no way to come up with an accurate estimate, estimates are just guesstimates. This thought was ethched in my brains, but I had to overcome this to be effective. Hence, I worked on a formula to increase my confidence over the estimates arrived based on standards used in an e-learning project estimation, and the formula is:
A (Estimates) = xx hrs
B (Project Loss Time) = 15% of A
C (Sub Total 1) = A + B
D (Labor Contingency) = 20% of C
E (Non Project Loss) = 15% of C
F ( Grand Estimate) = C+D+E
For example,
Estimates = 200 hrs
Project Loss Time = 200*15% = 30hrs
Sub Total 1 = 230 hrs
Labor Contingency = 230* 20% = 46hrs
Non Project Loss = 230*15% = 34.5 hrs
Grand Estimate = 230 + 46 + 34.5 = 310.5 hrs
I was satisfied with the result, and we submitted our estimates and were awarded the project. The estimates we made were almost correct (85% confidence), a great number to achieve. However, it did not stop me from exploring better ways to estimate effectively.
That is when I was introduced to Three-Point estimation technique. This technique gave me confidence in building an estimation process that has worked 95% of the time (for me).
The Three Point Estimation Technique is based on statistical methods (Normal distribution).
In Three Point Estimation, three values are calculated for every estimate:
a = the best case estimate (optimistic)
m = the most likely estimate
b = the worst case estimate (pessimistic)
These values are used to calculate weighted average (E value) for the estimate and a Standard Deviation (SD) where:
E = a + (4*m) + b / 6
SD = (b - a)/6
E is accounted both in the optimistic and pessimistic estimate, and SD measures the variability or uncertainty in the estimate.
To produce a project estimate:
· Decompose the project into a list of estimable tasks (Work Breakdown Structure)
· Estimate the E value and SD for each task
· Calculate the E value for the total project work as E (Project Work) = Σ E (Task)
· Calculate the SD value for the total project work as SD (Project Work) = √Σ SD (Task) 2
Then use the E and SD values to convert the project estimates to Confidence Levels as follows:
Confidence Level in E value is approximately 50%
Confidence Level in E value + SD is approximately 70%
Confidence Level in E value + 2 * SD is approximately 95%
Confidence Level in E value + 3 * SD is approximately 99.5%
Here is a tool developed based on Three-Point Estimation Technique for our documentation projects and it is based on ideas (templated designed) by Margie Yundt & Sherry McMenemy, Jim Chapman, and PMBOK . Although this tool is still a work-in-progress, I am happy to share what I’ve got so far.
For more on the tool, see my article on Three-Point Estimation Tool for Documentation.
No comments:
Post a Comment