Estimation is one of the vital factors for success of any project. Precise estimation and desired flow of execution of project will create good impression on client which eventually helps in generating repeat business. Sales department usually forces operation or project management for well defined and quick turnaround for an estimation. Many a times overestimates or delay in estimation costs loss of project and clients trust.
Managers play with few variables like requirements, time and resources (people, money) to decide estimation. Efficient estimators always consider unexpected changes with these variables while defining estimation. Extent of understanding of scope, domain/industry experience, strength and capabilities of teams involve in project are elements which usually made high impact on estimation.
Good estimation must include stuff which are not to be covered in project execution. Client will admire it and it might facilitate him to take any business/technology related decision. They always appreciate the company which will provide them accurate estimation and proper breakdown of the tasks/modules that need to be completed. It holds their trust that service provider properly understood the requirement and will develop and test the project in desired manner. Today’s most of the managers would like to go for Work Breakdown Structure (WBS). Estimate each and every activity, combine all, add some buffer and finalize the estimation.
Converting data into information is very important. When service provider received all requirements from client then they need to refine it in details as much as possible. It would be the best to give couple of days (depends on project size) to developers and testers to review and comment so all team will come on same platform of understanding. On proper understanding define the baseline that team should build throughout the releases. Define the indicators or responses that need to be estimated depending on factors. The baselines could be a simple guess for the first iteration that will be updated in the next iterations expecting some convergence and better accuracy.
Testing an application can also be measured based on:
1. Time to write a test (just the time to write the test procedure if manual and/or writing the test procedure and test script if automated). Time to write a test will initially be estimated using simple guess (where you apply some kind of factors). Just note somewhere your initial estimation and compare with the actual time it took. Do this for all the tests you’re going to write. It will give you refined metrics on the factor to apply to your initial estimations.
This should be split in different types of tests as your estimations will be more or less accurate depending on the category. In addition, if you have actual figures for each type of tests, you can easily apply similar figures for the next similar tests you still have to write. The next figures should be based on the past ones… experience counts!!
2. Time to run the test — It will initially be estimated using simple guess as well but if you’re using a good test management application, you’ll get the execution time automatically tracked by the system and some metrics computed for you (based on the last N executions of the same test). So the test management application should be able to give you in advance how much time it will take to run a complete test campaign – with very accurate numbers.
One can also identify the type of testing required as not all the projects required all kind of testing. Once categorize different types of testing like compatibility, performance, system integration etc. then identify high level scenarios and estimate those based on past experience. Add some buffer time to it and present the estimation.
In all approaches experience plays a vital role. Estimation might be different for same application if it will be carried out by different managers. Their experiences with similar project, understanding of domain and industry may vary which could end up in different estimations. Risk taking ability of managers also makes a difference in judgment. Research and learning about new concepts, confidence in team could bring optimistic estimation. It has always being the challenge to project management as how close their estimates are to actual.
References:
– http://bright-green.com/docs/howto_estimate.html
– Linkedin Software QA group discussions
