Scope creep is what happens when your project experiences changes and increases beyond its original mission. Your job is to make sure your team stays on track by referring to all your documentation anytime a question about scope comes up. You don’t necessarily have to reject every request for a change; you just have to put each request up against your original documents to see whether it’s a fit.
If a stakeholder requests a new requirement, you’d refer to your documentation in order to determine whether that’s something you originally signed up to work on. You can say “yes” to out-of-scope requests; just understand what happens when you do so by comparing each request to your documents.
When evaluating change requests, consider the project management triple constraint: scope (what work you can do), time (the amount of time you have to complete the work), and resources (the people and money you have to complete the work you signed up for). When a proposed change affects any one of those items, it impacts one or both of the other two.
How to spot scope creep in business analysis
To identify scope creep, follow these steps:
Examine the agreed-upon scope diagram for the project you’re working on.
Determine whether the request is within the area of study (the circle) or fits within the data flows and existing external agents.
If so, it’s not scope creep; it’s an additional requirement you need to account for. If it doesn’t fit, it’s scope creep.
Perform a rough estimate of the impact to the scope, time, and resources.
For instance, adding new requirements may do any of the following:
Necessitate additional time and/or resources (whether that’s financial or people resources).
Remove existing items from the scope and replace with the new items.
Request that the stakeholder complete an official change control document detailing the change and the reason for the request.
Estimate the change and report back to the stakeholder and the project team the change in the project scope, time, and resources necessary for the change.
The project manager decides whether to accept the change into scope.
You want to perform a rough estimate at this stage or at least advise the stakeholder of the consequences of adding new items to scope. You don’t want to spend a lot of time determining exact figures because every estimation task takes you away from your primary purpose — analysis!
How to formulate a change control process in business analysis
Change control is a process by which the project scope is changed. As with any project, you need to establish a formal change control process. Although some stakeholders may dread filling out change control forms because they think the forms are a waste of time, you need the forms so you can understand the rationale behind the change.
Change request forms create official artifacts for the request. Plus, when stakeholders have to fill out documentation every time they want to request a scope change, they’re less likely to continually submit ridiculous requests they don’t feel are necessary for the business.
The more stakeholders request and ask for change estimates, the more time the project team spends estimating changes rather than performing the analysis work for the project. Although you want to establish a good working relationship with stakeholders, you have to balance your estimates and helping on new stuff with the original requests and project scope.
Any official change request should contain the following items at a minimum. The first four fields are filled out by the requester; the last two are for the project team’s use:
Requester name and contact info: The requester is the stakeholder who is making the request. Contact information lets you contact the person regarding the status of the change and links the change with the stakeholder who will end up testing it during user acceptance testing.
Request date: Listing the date the request was submitted is important for understanding impacts. If the request comes in one week before a 12-month project is to be rolled out, instituting the change may be virtually impossible.
If the same request is submitted one week into the same project, the change may be much easier to make. The submission date may also align with other work packages (when solutions are being created), lessening the impact.
Change description: Of course, you need the stakeholder to describe the change she wants to make. Make sure the project team understands what is meant by the change. If not, members will need to make assumptions when they estimate the change to the project. These assumptions could be wrong and have negative impacts for the entire project. Go back to the stakeholder for clarification.
Reason for the request: This field explains why the stakeholder feels this change is necessary. The project team compares its estimates against this area to determine whether the change will have a good return on investment.
Estimated impact to the project: The project team determines the impact to the project by increasing the amount of time, adding additional costs to the project, and/or removing existing items from scope to fit in this item. Remember: Any change in time should come with a change in implementation date.
Assumptions: As part of the estimate, the project team completes a list of assumptions it made when estimating the change to the project. Any acceptance of the change request must take the assumptions into account.
You may also want to track other items as part of the change control process:
Time completing the change request took
Change request number (for traceability and identification)
Resources required
Who was responsible for creating the change request impact estimate
Date the change request was approved or denied
Sign-off from the project manager, project sponsor, and person submitting the change request.