The problem with many projects is that the scope is not very well defined at the estimation stage. There are a lot of assumptions made and these keep the project boundaries very flexible. Many a times, the assumptions are not documented, and even if documented, they are not ratified with the client/business. In this scenario, a change in requirements, or a scope creep is even difficult to identify. Hence the pre-requisite to arrest scope creep is to know what the project scope is during the time of estimation.
Requirements from client/business always keep on changing. But whatever the project team has agreed initially as the scope should remain sacrosanct. Even if requirement changes keep on coming, they have to be treated as parked items and should be relegated to the next phase or taken up as a change request. The project manager should very diplomatically say no to scope creep and put it in such a way that it does not mean that he will not take up the work, but that he can take it up only when other project constraints like time, effort and quality are changed. The best thing to do is to lay out the options before the client and ask them to prioritize between different requirements within the project constraints.
Requirements from client/business always keep on changing. But whatever the project team has agreed initially as the scope should remain sacrosanct. Even if requirement changes keep on coming, they have to be treated as parked items and should be relegated to the next phase or taken up as a change request. The project manager should very diplomatically say no to scope creep and put it in such a way that it does not mean that he will not take up the work, but that he can take it up only when other project constraints like time, effort and quality are changed. The best thing to do is to lay out the options before the client and ask them to prioritize between different requirements within the project constraints.
No comments:
Post a Comment