Ganesh KumarProgram ManagerBangalore., Karnataka, India
Specifications and requirements keeps changing most of the time, and Test Case also get modified. This impacts the Project Estimation as well.
Any suggestions, how to better specifications and resultant estimations. Saving Changes...
Sort By:
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Estimations are based upon the available information at that particular time. Things will change. Through progress, more is learned and absorbed into the project. It's necessary to have open lines of communication, trust, and transparency in order to regulate and prioritize the learnings into delivery of a product the satisfies the necessary outcome.
Short answer, estimations are just that and will never be accurate. Focus on outcomes. Saving Changes...
For software development I would use relative estimation (points rather than days or hours). Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
No problem with that. That´s not new. It happend and it is well documented from 1956 up to date. The best piece of work you can find to understand why and to create the strategy for that is Barry Bohem´s work, mainly "Cone of Uncertainty" which was created for software industry but it has been taken for lot of others industries. In fact, the numbers were included in past versions of PMBOK. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Ganesh,
yes, it is a old and well documented problem. Many mitigation ides exist.
One aspect is the overall duration of the project: The shorter the project the fewer changes and the less change impacts. At one client we calculated a percentage of the estimates as change efforts depending on the likelihood of changes, mainly driven by project duration (and also by homogeneity of stakeholders).
A further aspect is to re-assess estimates after you have data on similar tasks from the same project. Often the optimism bias led to underestimating efforts and you can correct your initial estimates. Beware of the learning curve though.
In any case, track all changes, even if the impact of each of them seems neglectible. The sum of many 0s is not 0 in this respect.
You may wish to look at Scott Ambler's great set of blog articles in the Disciplined Agile blog on this site for his thoughts on estimation and planning.
The level of estimation accuracy is inversely proportional to the level of uncertainty present in our understanding of the work to be undertaken. The less we know, the wider our estimation range and/or the shorter our forward-looking time horizon for making estimates.
Have you performed root cause analysis on why specifications and requirements keep changing? I admit, many of us see this as normal, or we've accepted that it's just how it is, but asking 'Why?" on occasion isn't a bad thing.
A quick brainstorm gives a few possibilities:
- the company culture is to rush to show progress and get things done
- projects are progressing slower than company/customer needs are evolving - you may be in a volatile market
- new information has become available; possibly due to changing needs, possibly due to planning delays or just poor planning
Like I said, just a few quick thoughts; I'm sure there are more possibilities. You can accept that things are how they are, and adapt. You might also find one or two areas where improvements can be made. You may not eliminate changing requirements and specifications, but you might make some positive improvements.
You might also find that office politics are at play and you need to approach things carefully.
Before you accept things as they are, understand why they are that way, then decide how to proceed. Saving Changes...
Ganesh KumarProgram ManagerBangalore., Karnataka, India
Thanks Andrew, another topic for future discussion would be "trust". Got it though.
Thanks David, I will connect with you to know more about "relative estimation", since estimations are mostly done by the
tech team.
Sergio as always thanks, certainly its not new, as you go along, the new lessons are learnt, and old are forgotten.
Thanks Thomas, noted, we thrive mostly on changes. More than underestimating, there a notion to estimate a little more to factor eventualities.
Thanks a ton Kiron, will refer the blog, just not able to find time for DA.
Thanks Aaron, yes we do rca, and one of them is that we have very little time to estimate. Another reason, at times the specs are such that customer themselves are unaware or would have not factored in, unless it comes into our hands. Saving Changes...
Community Champion
