How to Prevent Scope Creep | Scope Management

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.

Scope Creep - But Why Always | Project Management

image courtesy: http://www.relatably.com/q/img/inevitable-quotes/nothing-is-inevitable-until-it-happens-quote-1.jpg

This is not some fictitious account but facts presented in the form of a case study. A project in the construction industry with a budget of $10 Million was overshot by 20%. One might wonder what would be the margin then, clearly marking the bottom-line in red.

Root of the problem

When the builder was questioned about the glaring rise in the overheads, that went way over the budget, "it cannot be reported as scope creep though it turned out eventually." Haven’t we heard that before? “Yes, we have. And before you ask, this is not my first project. I am an experienced hand and I speak from personal experience, and that’s why 20 percent might sound whopping to you, is inevitable to me.  You speak about creep, like a leaky water pipe.  Then imagine in a massive water plant, one spot in a particular pipe will call for a complete overhaul of the plumbing unit. Don’t assume there is a quick fix like some adhesive pasted to block the leak. That’s a layman’s understanding. What actually takes place is more complex and cumbersome. Assuming, this took away a major chunk of the work from completion, you are looking at lapse in work which translated in hours and converted in dollars and cents can lead to sever deficit financially diminishing the returns. So to identify the root cause can prove painfully expensive.

The lesson learned, amongst many, can be the plumbing factor – which we naturally pay more attention and extra-cautious in the next undertaking. Then unbeknown, in the next project there will be some other issue out of the blue – it can be a wiring issue, for all you know.

Forces beyond

Risk is inherent. No doubt about it. But the nature of risk? How about a team member falling sick? Or the work done by someone isn’t thoroughly checked and impacts the development made so far? Or natural calamity or a strike? These don’t constitute creep but do attribute to scope creep one way or the other. Assuming a team member falls sick and the deadline has to be met. Sometimes, driven by deadline pressure or closure on dependency, one tends to crosscut and aim for closure. There are some risks to be taken, which may not impact short-terms but make you pay with grave consequences in the long run. Well, that again is a risk. So creep need not necessarily be direct, straight and said forth.

Creep is not something that can be defined or confined to a particular category. At best it can be contained is not clichéd. Objectively assessing, that’s reality because every project closure will script its own ‘lessons learned’ and yet we observe failings in some form. Incredibly, some repeated; it may not be intentional or ignorant but things that’s possible to be overlooked as trivia can prove to be a thorn and troublesome.

To wrap it up, we would want every lesson learnt to be put into use after all what is knowledge without application. Furthermore, the client’s expectation of earning more for every penny needs to be professionally managed. Expect the customer to come up with last minute surprises, that is strictly out of scope but then you can’t say ‘no’ not wanting to offend. Hence one should draw the line somewhere without hurting either party involved. It’s a thin line that calls for a fine act. We don’t want scope creep – it just self-invites. That’s scope creep. I just gave you a long-winded definition."

Scope Creep Inevitable?

Inevitable? So there is no way out? There are ways to mitigate but Scope Creep control has everything to do with you.  We started with why is there scope creep always.  And also, we stated categorically that creep can be contained.

How do you contain scope creep? We will discuss the ways in our next posting. Meanwhile, if you have any ideas, suggestions, theories, or experience, please do share and educate our users.