Introduction to Scope Creep, Scope Changes, and Project Scope Management
Scope creep refers to project scope changes that aren’t controlled. Scope creep is not paid for. Every project needs to have a Change Control Board that reviews scope changes requested. A Change Control Board is critical to successful Project Scope Management. Scope creep leads to providing the client more at the expense of project resources and project budget. Controlled scope changes, however, leads to providing client value without sacrificing on project resources.
In this article, we’ll look at three actions you can take to control scope creep and uncontrolled scope changes. This information is relevant to the project scope management knowledge area.
Reduce Scope Changes by Collecting Requirements Properly during Project Scope Management
The fundamental source of scope creep (uncontrolled scope changes) in scope management is during the collection of requirements (Collect Requirements process in the PMBOK version 4) in project scope management. Inadequate requirements collection stems from when you have rushed through the Collect Requirements process in the project scope management or when you haven’t collected the requirements from the most appropriate sources. Project managers rush through the Collect Requirements process during project scope management when they are eager to get some quantifiable deliverable out on the market. Many times this is because there is another organization that might launch a competitive product. The pressure to deliver leads to taking short-cuts in collecting requirements. Over the project cycle, this leads to scope creep (uncontrolled scope changes). The best way to avoid this is by making sure there is enough time planned for collect requirements. Also, you should be able to convince the client of the need for collecting requirements accurately. Try educating the client of the consequences of uncontrolled scope changes in the project lifecycle. You should also educate the client of the processes involved in project scope management.
Even if you have spent time collecting requirements as planned, scope creep (uncontrolled scope changes) can arise from not using the best sources and techniques to collect requirements. You can survey the people involved and observe potential users of the system being developed. This will result in many hours saved in rework activities.
Use Consulting Skills to Control Scope Changes in Project Scope Management
Many times, customers don’t really know the most optimal approach. It is up to you to provide this solution. Don’t assume the customer is always right! Take your time to assess the scope creep (uncontrolled scope changes) and then make a decision. Project managers often get pressurized into making scope change decisions that come from the client. This then leads to the team working insane hours to deliver something that may not even be the solution to the customer’s business problem. Don the hat of a consultant and probe until you have the answers to make an informed decision on the scope changes. Using the latest brainstorming techniques will help you. You’ll be surprised at how much this will be appreciated by the “know-it-all” clients.
Successful project scope management requires a project manager to understand the business problem first and the reasons why the client asks for scope changes.
Commit Only When You Are Certain About the Scope Changes in Project Scope Management
Scope changes can come from multiple avenues in the project and they are expected. Similar to how you wouldn’t make a critical life changing decision, such as marriage, without knowing a lot about the person, project scope changes decisions should not be taken lightly. Actually non of the project scope management processes should be taken lightly. Research on the scope changes and then make the decision. You’ll be surprised in what you’ll find. Uncontolled scope changes and controlled can lead to regression errors. Therefore, your risk register must be updated with the risk response strategy. Project scope management does not exist in isolation of the other project management processes!
Let’s take a scope management example. Suppose your client wants the application to be compatible with at least four browsers. Initially, the client wanted it to be compatible with only one browser. You might be tempted to think, that’s easy. A few lines of code and we should be set. However, did you account for the testing that is required? It’s four times as much, since the application will need to be tested on each browser. Similarly, they’ll be other activities that’ll crop up. The project critical path may also change.