Scope creep is a project management term used for describing the situation where unmanaged changes to requirements, continuous uncontrolled expansion of requirements or miscommunications and disagreements about how requirements are to be constructed occurs.
Scope creep is harmful to businesses and their projects. It is the cause of budget ‘blow outs’, missed deadlines or milestones and failed delivery of anticipated software, apps or other technology.
Why Does Scope Creep Happen?
Generally scope creep occurs through misunderstandings between the various people involved in the project.
Misdirected Requirements Gathering
During ‘requirements gathering’ aspects of the solution forming process can be inadvertently directed to focus on things that are unimportant or unaligned to the purpose of the project. For example, a deep understanding of the business’ desires may overlook operational realities. The desire to make a project inclusive by involving outside parties can introduce problems that the project owner was not intending to address.
Where projects have multiple outsourced or across business implementation teams. Poor communication of project requirements, business goals or acceptance criteria, may be caused by different styles of information sharing.
Cultural differences in communication, from document layouts to ambiguous jargon lead to incorrect assumptions that bleed into projects. Egos, rivalries or competition caused by KPIs and rewards structures can also be a cause of restricted communication – the intention to protect a team, leading to harm for the overall project.
When coupled with poor or non-exist feedback or ineffective review meetings, scope creeps.
‘Creative freedom’ (the ability to invent or develop from a high-level conceptual idea) in projects often results in functionality, features and use cases that differ from what may be anticipated.
Providing little guidance to developers forces them to ‘fill in the blanks’ when creating solutions. Resulting in outcomes with unexpected behaviours, inefficient ‘cool’ interfaces or frustrating operational flows. What a developer or engineer thinks “you are going to love” may be the absolute opposite of your vision and may lead to project abandonment.
Striving for the perfect solution introduces the risk of well-intentioned yet unnecessary features and overbuild (to build beyond actual demand or need). Usually fuelled by the desire to exceed expectations, perfectionism is wasteful in terms of time and resources and frequently leads to complications – in the code, architecture, testing and even in post roll-out management and maintenance.
User acceptance testing (UAT) is the stage of a project were the people who will make use of the project solution are asked to review, test and assess for day-to-day business operational use. It is where the success or failure of a project is usually first identified.
Misunderstood intentions and optimistic commitments often show up as ‘errors’, redundant features and unexpected variations that require ‘rework’ (it is estimated that 50% of a project’s final cost can be directly attributed to rework) and cause delays.