As a business analyst, it is important to know the difference between project scope, product scope, and scope creep.
Project Scope is the work that is required to be completed to deliver a product, service, or result with the specified features and functions. The Project scope should be the responsibility of the Project Manager.
Product Scope is the functions and features that characterize a product, service, or result and should be the responsibility of the Business Analyst.
Scope creep refers to the increasing scope of a project after the initial scope has been defined which may include additional requirements that may not have been a part of the initial planning of the project while failing to adjust for budget and project timelines.
Project scope tends to address “how” a project will work while Product scope is geared towards “what” a project needs to be successful. Here you will find functional requirements.
Scope creep can happen if the requirements are not completely defined or described during the elicitation phase. Scope creep management can help reduce scope creep. Without proper scope creep management, you run the risk of going over time or budget, missing needed requirements, or not being able to deliver the product at all. Scope creep management should be included in all project and product requirements activities.
Different forms of scope creep include:
Business scope creep – Occurs when the needs or requirements of the business are often the result of poor requirements definition early in the requirements phase, or the failure to include the project users until the later stage of the SDLC.
Features scope creep – Occurs when the scope creep is introduced by programmers, designers, developers, or stakeholders adding features not originally contemplated.
Customer pleasing scope creep – Occurs when the desire to please a client or customer changes or increases the product features thus adding additional work to the current project.
Gold plating scope creep – Occurs when stakeholders change the original requirements because they know “a better way to do it” or because the initial requirements were unclear.