How to Prevent Scope Creep Scope Management

Oct

Continuing from our previous post of containing creep, we have listed 10 pointers as useful reference to amplify your project management skills. Scope Creep management is primarily handled by a PM and hence it’s a fair expectation to observe the call taken to neutralize creep. Scope Creep is a way of practical life, and hence one can, at best, contain and thereby control. Team management must ensure some overzealous team member overstepping in reach by getting in touch with the customer, who might influence changes that might sound simple like ‘bells and whistles’, and also the peril of Gold Plating –whereby “After having met the requirements, the developer works on further enhancing the product, thinking the customer will be delighted to see additional or more polished features, rather than what was asked for or expected.”

Get the requirements clear Sometimes,

it might be iterative but unless all the stakeholders involved are the in same page, especially the client and vendor an converse in the same language and understand one another, closing all possible gaps, and if possible walk-through the requirements once again. It might burn some bandwidth but it will be worth it.

Pay attention to the detail

From the first piece of code written to a single line drawn in the wireframe, make sure everything is as per agreed terms and within scope. From experience, it may be noted that design and development inexplicable makes way for creep. So ensure that a sign-off is sought on design aspects, and read the requirement document again before commencing coding

Divide the requirement into small logical parts

Smaller projects have a much greater chance of success, so smart PMs do a work-break-down in creating sub-tasks so that the effort estimated and actual; spent can be controlled better. It is always easy to divide the requirements into small logical parts and assign the corresponding effort against it.

Identify priorities

You will need to decide on the scheduling as to which will go first followed by or will there concurrent tasks. And identify the deliverable and break the deliverable into actual work. In case of larger project, it might mandate upgrades which need to be factored for effort and hence breakdown of deliverable helps.

Plan for Prototype

When the requirement/solution is not clear, plan for Prototype/Spike User Story before finalize the scope.

Understand the requirement

Reverse Understanding/document for the Customer to ensure that requirement/expectation is well captured .

Capture revision/changes

Have clear understanding on implication of the revision/changes in the requirement and document the agreement.

Change Control Board

Make sure there is a Change Control Board in place to track any deviations from the accepted and scoped requirements. Changes, if any, need ti be recorded, communicated to client for confirmation and only upon their explicit the changes can be accommodated, that too at a timeline best suited to the project interest. Bottom line, it’s out of scope which becomes a part of development through Change Request.

Present the impact Analysis in detail

When there is request for Scope Change, Present the impact Analysis in detail as Technical or Design Impact on effort and Cost, especially through rework and lost effort.

Study Intangible impact

i. Moral of the team

ii. Trust factor with the Customer

In any case, the Scope Change has to be treated as Change Request. Regular review meeting with Customer on Progress Status Vs Plan should be conducted to eliminate creep as much as possible.