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:
- Lack of clarity about project scope.
- A miss in capturing the essential or implicit requirements.
- Adding features that do not contribute to business benefit or of value add.
- Client may be under pressure with a competitor and hence would like to introduce additional features/functionalities
RISKS INVOLVED DUE TO SCOPE CREEP
- Scope screep has negative impact on a project as the project may be derailed in terms of timelines and may overshoot budget.
- Leads to financial loss in case a project gets cancelled.
- Leads to client dissatisfaction.
- Leads to lot of rework as the scope keeps changing.
- 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
- 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.
Cartoon by Thomas A. Tinsley
- 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 for an 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.
- 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.
- 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. Churchill
About the Author
Kiranmayi Satnarayan has over 12+ years of experience into IT industry with an exposure to Business Analysis, Project Management, and Software Development. She completed her Masters in Computer Applications in 2000 from Osmania University and was involved in many IT implementations working on requirements, design, and development. She later went on to pursue Exec-MBA from XLRI in 2009 and was PMP certified in January 2011. She is currently working as a Senior Business Analyst in an MNC Bank based out of India and is passionate about Business Analysis.
Powered by Facebook Comments