 |
| image courtesy: http://i0.wp.com/galvintech.com/wp-content/uploads/2014/09/How-to-Prevent-Scope-Creep.png |
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.
