Managing Scope Creep

However well defined your SOW document, however detailed your SRS document, some amount of scope creep is inevitable during the development phase of a software project. When a customer previews the system that is being developed, they are bound to come up with new ideas on how a particular module, report or web page should look. Of course, a strong project manager or project sponsor would try and negotiate a corresponding increase in either the budget or schedule or both, in which case, the increase in scope would be treated as an acceptable change request. But if the customer is a VIP client, or if your initial project documents were not specific enough about the scope, you end up having to accept the changes and work them into your schedule and budget. Your best best in such a case is to try and minimize the impact of the scope creep, especially on the confidence of the development team. You could do this by asking the customer to prioritize the changes and ask your team to target only the high priority items at first. At the same time, you would have to negotiate with the customer and set reasonable and realistic expectations about the timely completion of the changes. Most customers would be willing to concede some extra days for low priority changes, beyond the implementation date of the project. Of course, keeping the team engaged for longer on one project could affect the schedules of other future engagements. But, as a project manager, you would still end up having made the best of a bad situation