Software size and effort estimation has been a keenly debated subject since the last few decades in the IT/software industry.
The concept of size is related to the "amount of work that needs to be done" and not "what it would take to get the work done", which is actually related to the concept of effort.
The "amount of work that needs to be done" is a reflection of the output whereas "what it would take to get the work done" is a reflection of the input.
Many a times this distinction is either misunderstood or forgotten as an estimator goes about estimating.
Estimators, especially the star ones, are certainly experts in a specific domain.
However, this expertise, makes the estimators think of themselves as technical wizards and masters of engineering magic. And therein lies the core problem.
One challenge in estimation is related to the process or the method aspect.
Star estimators would directly estimate the effort using a task or work breakdown structure. Putting effort against the various line items and then adding it all up they come with the effort estimates.
So what's really wrong with this?
There is not one thing that is wrong with it, there are several things that are wrong with it. Here are some of the major points to ponder about:
Estimation in any organization is done by the the supposedly "wizards of technology". These are folks who are the blue-eyed boys of the management.
After all, they are the ones who help win business deals. Only they can create estimates and proposals and bedazzle prospective customers with their technical and domain skills to bag the project.
So who would question such estimators? Anyone? Did you say the management? Well you know the answer, you really do know. No one!
So unless the star estimators take lead in using size estimations, it will not happen. And they will not do it because it will force them to adopt a scientific and structured method and expose them to a lot of necessary criticism.
Keeping things fuzzy helps them maintain their star status.
In some organizations, the proposal-time estimates are not tracked throughout the project along with the revisions on the way that are necessitated by change requests.
And the most surprising thing is that in such organizations the star estimators have no compulsion to or interest in asking for the actual data on size and effort at the end of the project to compare and analyze the deviations against the estimates of size and effort.
Only when a project goes horribly wrong does the management say something. Of course, they can't say anything to the star estimators directly. Why? What if they leave?
So the management puts up a committee or task force to improve estimation practices. None of the star estimators is made the head of this task force.
The head is made from another group so as not to ruffle the feathers of the star estimators. Why? Again, what if they leave?
Unless the people angle to estimation is not addressed the maturity of size and effort estimation practices will continue to remain in the state it is currently.
The concept of size is related to the "amount of work that needs to be done" and not "what it would take to get the work done", which is actually related to the concept of effort.
The "amount of work that needs to be done" is a reflection of the output whereas "what it would take to get the work done" is a reflection of the input.
Many a times this distinction is either misunderstood or forgotten as an estimator goes about estimating.
Estimators, especially the star ones, are certainly experts in a specific domain.
However, this expertise, makes the estimators think of themselves as technical wizards and masters of engineering magic. And therein lies the core problem.
One challenge in estimation is related to the process or the method aspect.
Star estimators would directly estimate the effort using a task or work breakdown structure. Putting effort against the various line items and then adding it all up they come with the effort estimates.
So what's really wrong with this?
There is not one thing that is wrong with it, there are several things that are wrong with it. Here are some of the major points to ponder about:
- How can anyone say how long it would take to go from point A to point B if they don't know the distance (size attribute in this case)?
- Of course, the time taken is not only a function of distance and depends on other factors too like the traffic conditions, mode of travel, driver skills, etc. but they vary unlike distance
- The "amount of work that needs to be done" shouldn't change at a fundamental level but "what it would take to get the work done" can change with changes to the climate variables
- Effort for creating a size depends both on the size as well as the conditions under which the size is getting created which includes factors like complexity, productivity, team competency, dependencies, assumptions, etc.
Estimation in any organization is done by the the supposedly "wizards of technology". These are folks who are the blue-eyed boys of the management.
After all, they are the ones who help win business deals. Only they can create estimates and proposals and bedazzle prospective customers with their technical and domain skills to bag the project.
So who would question such estimators? Anyone? Did you say the management? Well you know the answer, you really do know. No one!
So unless the star estimators take lead in using size estimations, it will not happen. And they will not do it because it will force them to adopt a scientific and structured method and expose them to a lot of necessary criticism.
Keeping things fuzzy helps them maintain their star status.
In some organizations, the proposal-time estimates are not tracked throughout the project along with the revisions on the way that are necessitated by change requests.
And the most surprising thing is that in such organizations the star estimators have no compulsion to or interest in asking for the actual data on size and effort at the end of the project to compare and analyze the deviations against the estimates of size and effort.
Only when a project goes horribly wrong does the management say something. Of course, they can't say anything to the star estimators directly. Why? What if they leave?
So the management puts up a committee or task force to improve estimation practices. None of the star estimators is made the head of this task force.
The head is made from another group so as not to ruffle the feathers of the star estimators. Why? Again, what if they leave?
Unless the people angle to estimation is not addressed the maturity of size and effort estimation practices will continue to remain in the state it is currently.
No comments:
Post a Comment