It’s always a big challenge for a project manager to deal with scoping the work product. I guess reasons for the same we all know as mentioned below.
1. Customers always want more.
2. Architect/ Tech leads thinks every one in the team is as capable as they are.
3. Team always thinks estimation is very aggressive so thats why every one has to stretch their working hours.
4. From organization perspective, organization wants that customer should be always happy.
Here are 10 points that I follow while dealing with such situations.
1. Make estimates considering average capability resource of your team. Estimating keeping high capability resource in mind may lead you to over estimating situation and estimating keeping low capability resource in mind may lead you to under estimating situation.
2. Always include time spent in miscellaneous activities like (work delegation, build promotion to different environments, meetings, communication etc.) in estimation before starting scoping.
3. Before starting scoping request feature priority list from customer so that you could know what will be acceptable to customer if dropped while scoping.
4. While scoping never go by count of features rather go by your estimates. Some time we think that count of features is less than previous releases we have made so we start searching out a way to keep the count same but that does not work practically. you should always stick to estimates rather than feature count.
5. Level the complexity of a release, try to distribute high complex items across iterations/phases of project and make sure that complexity of each iteration/phase is leveled appropriately.
6. Before getting into scope discussion with customer make sure that you have done enough of ground work and you have ready references available for all high valued items estimates as most of the time discussion will be focused on high valued items only.
7. Never estimate for shadow staff given to your team. It does not mean that you will not give work to shadows, they should be used to share load of main resources.
8. Review the scope twice before sending it to customer because you should be convinced fully before customer or any one else accepts it.
9. Keep eye on productivity figure of previous releases you made this should fairly give you idea what can be covered and what can not be.
10. Never plan to deviate from processes to cover extra scope. This will lead you to serious quality issues.
There are off-course more additions you can make to list but for now i think above are quite helpful while doing scope negotiations.