Scope Creep:
When we start any project, one of the key initial steps that we take is defining scope (What is in-scope and what is out of the boundary, i.e., out of scope)
Change is unavoidable so Change in scope is also inevitable based on current performance and situation.
Anything (additional features, requirements, considerations to existing) that is added over and above the accepted/agreed upon scope is Scope Creep.
Would like to quote an example from software development (traditional - Water Fall and agile) or even in an DMAIC six sigma project scope creep can happen at any of the phases.
Below image gives a view of scope change iterations in each sprint delivery in an agile environment
Iteration scope change along with Scrum Master’s expertise will allows better management of scope change and control it.
Simple definition of Scope creep would be any changes that is introduced to the project post requirement gathering phase.
CHANGE is not usually Bad !!!
Change is necessary in order to sustain competition
When do we usually have scope creep?
It can be Market Demand, New Technology, Change in Business Need, Development Constraints
Some of the additional scenarios would be
When change control is uncommon
Poor scope identification (initial analysis) and definition during project charter stage
When communication is not apparent
When there is external Influence
Bad project planning and deployment
Dynamic market change
Quick change over / Late point differentiation (Usually for a matured process/product)
When Project Manager is frail
When initial scope definition is no more applicable
Impact of Scope Creep:
Project cost overrun
Mix-up / Misunderstanding of new requirement
How do we identify Scope Creep:
Scope definition itself is not a simple process, it has various below steps / documents, viz.,
Scope Planning,
Scope Definition,
Scope Work Breakdown Structure
Scope verification &
Scope Change Control.
So scope definition is obviously critical and vital step.. so when ever there is deviation or when there is a scope creep, we will have to rapidly take necessary immediate actions.
Identify scope creep by when there is misalignment with objectives, deviation from deliverables, multiple change request from external stake holders, and most importantly anticipate and ensure availability during scheduled project connects [Do NOT wait for situations to come up, Be Proactive] .
How do we avoid Scope Creep:
Document the requirement details
Create SMART objectives
Deploy Change Control Plan
Prepare Clear and Attainable Project Schedule
Verify, Validate and get SING-OFF from Stakeholders (before project start)
Engage the team
Create SOW (Statement of Work) to outline the work
and monitor development progress
How do we manage Scope Creep:
If we are not managing Scope Creep, it could possibly have Negative impacts.
Use a good project management tool/applications at your disposal (such as JIRA, Trello, Easy-projects) and In order to manage the changes some of the below best practices / actions can be taken
Define / Re-define the project scope
Re-baseline / measure change difference (Work re-estimation. Agile Eg., T-shirt sizing exercise with the development team)
Keep all stake holders informed
Update project cost document (Request for extra resources / cost if required..)
Update new target dead line / milestone document / Gantt Chart and communicate with project team, sponsor and supplier
Reprioritise WIP
Managing Key Project team Members, Stake Holders and Users:
Keeping everyone informed is critical and is necessary in projects. so keep customers, users, members and stakeholders engaged.
Be Agile
Create 2 ways communication channel (Through tool/application/forums/meetings)
Ensure regular updates and information is available to all stakeholders at any point of time
Ensure time schedules for meetings are feasible and if required Re-schedule and Do not cancel meetings with out reasons
Keep RACI Matrix updated and Key SPOC's defined during the project
Maintain relationship and request sign-off whenever required
Get USERS using the product or service at early stage
It is Ok to say "No" when it not possible to accept scope change (final stage, 11th hour feedback, when change doesn't make sense,...)
Keep developmental progress and details transparent. This would ensure team members are not demotivated and diverted from the objectives.