How to prevent Scope creep: A Business Analyst perspective
Many years ago few of my colleagues started working on a project, which was not so complex. It went well for the first few months. The problem started when the team travelled to client location to give a demo on a module to seek client’s feedback. The client suggested certain changes that were accepted by the team. The team built the module with new suggestions however, the client suggested few more changes. After a couple of similar back and forth interactions, this situation gradually led to passing the buck in the blame game between the client and the development team. The project was ultimately shelved by the company as it was no longer delivering a good ROI since the client refused to increase the time and the budget any further.
Situations like above may not only lead to rework, wastage of time and effort, financial loss but may also result in huge customer dissatisfaction leading to loss of repute in extreme cases. Additionally resources working on such projects would be more than willing to exit such projects.
Could this have been prevented? My answer to that is a resounding ‘YES’. Before we venture further on how to prevent situations like these, let us define and examine few facts so we have clarity of thought.
What is a Scope creep?
The scenario that we just discussed in the beginning is called ‘Scope creep’. Simply put Scope creep is an uncontrolled change to scope that has an adverse impact on the project and where the client is usually unwilling to bear extra costs or extend time.
Why does a Scope creep occur?
Majority of the reasons contributing to scope creep are:
1) Lack of clarity about project scope.
2) A miss in capturing the essential or implicit requirements.
3) Adding features that do not contribute to business benefit or of value add.
4) Client may be under pressure with a competitor and hence would like to introduce additional features/functionalities.
Risks involved due to Scope creep
1) Scope creep has negative impact on a project as the project may be derailed in terms of timelines and may overshoot budget.
2) Leads to financial loss in case a project gets cancelled.
3) Leads to client dissatisfaction.
4) Leads to lot of rework as the scope keeps changing.
5) Dissatisfaction in resources aligned to a project.
Now that we have defined what a Scope creep is, gained some ground on the various reasons driving it and listed the potential risks involved, let us discuss what a Business Analyst ideally does or can do to prevent situations like these.
How to prevent Scope creep
1) Understand Project Scope: It pays to understand the real business need, higher-level goals, and business objectives of a project. The Big picture helps the BA to get a clear understanding on the project scope, which in turn brings clarity on the requirements that are inclusive to the project.
For example: From the Reporting requirements, perspective, the original specification was to view, download, and print the report directly from a portal. A few days later, the client mentions that it would be good if the reports can be emailed via portal. This request definitely falls out of scope.
Refer Fig 1
2) Document requirements exhaustively: While documenting explicit requirements can be a cakewalk, gathering implicit requirements are tough nuts to crack for a business analyst. In this case a business analyst could employ well-known techniques like Use case modeling, Prototyping, observation etc to effectively gather the assumed and unstated requirements of the client.
For example: Consider a scenario where a call center executive needs to capture all the relevant information from the client in a matter of minutes by keeping the customer engaged. Taking too much time may not only irritate the client but it could affect the executive’s servicing SLAs. Bearing in mind the business need to capture data efficiently and quickly, a requirement foran intelligent screen layout that facilitates quick data capture could be drafted. This not only makes the executive’s job easy but also helps the business in meeting its customer satisfaction goals.
3) Educate the client about the change control procedures: A BA could educate the client on not to rush during requirements gathering stage and thereby making the client realize the perils of uncontrolled scope changes. He/She could also appraise the client about Change control procedures and appropriately warn the client about the additional costs associated with a Change Request.
Refer Fig 2
4) Trace the Requirements: Performing effective Requirements Traceability helps in identifying those features / functionalities that are of value can be traced to a business benefit thus helping in weeding out any extraneous features and in identifying any dependencies.
Any change to scope needs to be handled with caution and supported by an impact analysis followed by a cost benefit analysis. As fallout of this analysis, a change may or may not be accepted. However, any change with no impact on time and budget rendering huge business benefit to client can be accepted.
“It is not enough that we do our best; sometimes we must do what is required.”
– Winston S. ChurchillTags: BA Scope