How To Manage Scope Creep ?

Uncontrolled changes are often referred to as project scope creep. Adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval.

Project scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. Scope control assures all requested changes and recommended corrective actions are processed through the project Integrated Change Control process.

SET: 
Change in scope affects schedule and cost. Set the expectations and outcome accordingly. 

Manage:

If you are executing the project under Fixed fee contract, get approval for change request to raise separate invoices.

If you are executing the project under T&M contract, estimate the cost and schedule for the CR and update the customer.

Now-a-days, organizations move towards Agile methodoloy not only time to market but also to changing the features often

We were hired and assigned to the project because of our knowledge and expertise in the solution required. RIGHT

So , If a client requests for an additional features, try convincing them that having the same old feature will provide a better solution than the new one. Don’t be afraid to contradict unwise feature requests; providing well-formed reasons will assure them that you know lot more than them (actually you do know), and they may actually allow you to proceed as originally planned.

Normally SCOPE SCREEPS occur mainly on account of the fact that the key stakeholders WANTS and EXPECTATIONS were not read, understood, docuemented and converted to PROJECT SCOPE...!!

This GAP in the PROJECT SCOPE expected by STAKEHOLDER and that udnerstood & provided by CONTRACTOR leads to SCOPE SCREEP...!!

Scope Creep can occur first from improperly understood requirements. This is an internal problem and cannot technically be called a customer-generated scope creep. The solution for this is a proper translation of the "English" requirements to "technical" requirements, the creation of a WBS for the same and getting the customer concurrence for the same. Along with this, in parallel the creation of a Test Plan for each of the WBS elements. This, if shared with the customer and duly signed by both parties will ensure no scope creep. ALL the activities shall have to be traced from the WBS to the Technical requirements(generated by you) to the English requirements (generated by the Customer). Once signed by both parties, scope creep does not exist.

Another area for the scope creep comes because of the "learning" that is done by the customer at our expense. These are the true scope creep and will have to be handled as a separate issue.