It'll be every project manager's wish to not to have to deal with scope creep issues in his / her projects. However, still there seems to be no tool or technique available to entirely avoid scope creeps in any project across the seas. Even the PMBOK(r)Guide-5th ed has not addressed this issue to the depth it should have been. We all know that uncontrolled scope change is scope creep.
PMBOK Guide Cl 5.1 Plan Scope Management. .. last sentence says ... "This plan ( scope management plan) HELPS REDUCE the risk of project scope creep." Note here the word REDUCE, not AVOID. Can we say no document / plan can AVOID scope creep entirely.? A well developed Scope Management Plan can only help REDUCE scope creep.
IMO, in any project, SOME scope creep is UNAVOIDABLE as 100% se can never be captured or documented during tender / bidding / contract-award stage. Even in well defined projects, minor changes/additional works will creep in without proper change order (CO) and this is to be handled carefully as it is culturally sensitive issue.
Hence, it''s better to identify it as potential risk and provide some contingency reserve (CR) for it at project manager level. The management also should anticipate some unknown-unknowns in the form of scope creeps from Clients and manage such risks through Management Reserves (MR) for smooth execution of project and enhanced customer satisfaction. Or,
Is scope creep an unavoidable cultural issue across the world? Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sorry, but I have disagree about there is not a tool. Change Control process (change management process PLUS configuration management process) is the tool to deal with scope creep. And understanding that the project manager do not decide about changes. Saving Changes...
Sergio,
Please note that Scope Creep is an uncontrolled expansion to project or product scope without any adjustment to project''s time, cost or resources.
Change control process is mainly used to control Scope Changes which are changes to project scope and they almost always require adjustment to project''s schedule or cost.
Changes to project scope ( product scope) are formally presented through a Change Request (CR) and are reviewed by the Change Control Board (CCB) for approval or rejection of a change request.
Hence, CCB does not deal with scope creep. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sure, I understand. And that is because the change control must be followed. If you follow a change control process then scope creep does not exists. Not foloow a process is a matter orf governance and quality, not culture. Saving Changes...
If scope creep does not exist, why PMBOK(r)Guide addresses it and mentions it at several places.
Scope creep is very common in most projects around the world. The problem with scope creep is that there is no single,formal,right tool or solution to it.
How to approach or handle a scope creep situation is entirely left to the project manager in most cases, and unfortunately many project managers are not adequately experienced to handle scope creeps in a professionally manner.
It''s could turn out, sometimes, to be a culturally sensitive issue and if not handled properly, it can potentially put project objectives at stake. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I said that if you follow a change mangement process then scope creep does not exists. I am not saying that scope creep does not exists. And you are wrong about scope creep is very common in most of the projects around the world. it is common in project where a change mangement process is not definied and implemented. If as you mentioned scope creep is left to the project management then it demostrate that is not reason to have a project manager assigned to the project. Here comes other topic to take into consideration: what is assigned, is a project manager or other type of role (project coordinator, etc)?. What is organizational culture? Are values and behaviour that emerges for people understanding about organizational policies. So, its a matter or quality (process implementation) to work on creating a culture to avoid things that scope creep. Once again, it is a matter of process and governance, not a matter or culture. And this is in the field of project quality. Saving Changes...
Thejassu RaghavanEngagement Manager in Agile environment| WinWire Technologies LtdBangalore, India
Sergio is right.
If you are controlling the scope changes through CCB, how can there be scope creep. If the scope changes happen with out control then you have scope creep. Saving Changes...
Read all the posts /inputs first before passing your professional judgment as to who is right or wrong.
Your understanding, of what a "scope creep" or "scope change" is, needs a complete revision by you before passing quick judgment even when no judgment was sought.
It''s funny that your own second statement defeats your first statement in your above post.
You are using the word "scope change" very casually or loosely which indicates your poor understanding of both scope creep and scope change.
Even if you are controlling the scope changes through CCB, there could possibly be scope-creeps. It depends on the Client''s change management procedures, procurement practices, culture, and ethics policies. You may note carefully that Scope change and Scope creep are two different independent things and both can simultaneously present in a single contract. One is not dependent on the other nor can we say if there are scope changes, there won''t be scope-creeps.
The question is "Is scope creep an unavoidable cultural issue?. Saving Changes...
saurabh mahajanPMP, ITIL, PRINCE2| vodafonePune, Maharashtra, India
Scope Creep : This can occur when the scope of a project is not properly defined, documented, or controlled.
That means new requirements (that client wants) which was not discussed and agreed earlier OFFICIALLY
So for defining it properly and accurately your requirements management process should be well defined and followed. This requirements when freezed should be documented and approved by all stakeholders. Then comes manager's role to control the change. For every uncontrolled scope growth to deliverables, manager should refer to this requirements document which is signed by all parties and agreed.
The other part is, during hectic project schedule this basic steps might not be followed and scope creep can occur. So the decision is of manager (ideally of every project team member) to follow or not to follow the basics. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
@Ondiappan: just a question with all my due respect: why do you post a question if after receiving answers you do not accept it? What @Thejassu state is an opinion and it is correct. You have to review your answer. If you control the changes then scope creep does not happend. You can control the changes in the way you want (while I have my personal opinion on that) but you have to control the changes. If not, the whole process (the project) will be out of control then to have a project manager assigned has no sence by definition. What others and myself are saying is: it is not a matter of culture. That is the answer of your question. I am spending my time in this type of topics to learn from others comments. Perhaps somebody will write something diferent and I will learn by exchanging our opinions. It is not correct to say that if you control something then it will exist. If exists then it is out of control. And if that occurs, following quality principles, you have to review your process and you have to go to senior management to search for the causes. Saving Changes...
You said in your first post very confidently that there is a tool to deal scope creep and the tool you suggested was "change control process".
Later, after a few rounds of my inputs, you have changed your views and now you say if you control your process scope creep does not happen.
I also said in my last post change control process is there only to process formal scope changes submitted through Change Requests (CR) and not for processing scope-creeps. Scope change and scope creep are two different things and one does not deter or facilitate the other.
Please read all my previous posts carefully and if you still feel scope creep can be handled through formal change control process, you follow it.
Quality has nothing to do with scope creep''s occurrence or non-occurrence or its management.
If you feel scope creep is not a matter of culture then what, on earth, prompts clients in some countries, as matter of habit or practice, to initiate an uncontrolled excess (i.e informal request for an extra work or item) to product or project scope without granting extra time or budget?
One need to have wide domain exposure and/or experience in various countries to feel or experience the scope creep and to properly answer it or handle it.
If it is not a "generally recognized practice", why would PMI, in its PMBOK Guide, bother about addressing scope creep, caution about it and expect PMs to be aware of such practices.? Saving Changes...
