What is Scope Creep?
Scope creep is the gradual expansion of a project’s requirements after the scope is agreed, usually through small additions that each seem too minor to renegotiate. A single extra field on a form is trivial; the same field arriving eleven times, each with validation and a migration, is a schedule that no longer holds.
- Category
- Product & Delivery
- Also called
- Requirements creep, Feature creep
- Related
- Software Requirements Specification (SRS)Fixed-Scope vs Time-and-MaterialsDiscovery PhaseProduct Roadmap
- In our work
- How we price projects
The cause is rarely bad faith on either side. Requirements genuinely become clearer once screens exist, and a client seeing a real interface for the first time notices things no document surfaced. What separates healthy change from creep is bookkeeping — a change that is written down, priced and scheduled is a decision, while the same change absorbed quietly to keep a meeting pleasant is a cost someone pays later in overtime, quality or goodwill.
The mechanisms that hold it in check are unglamorous. A written baseline both sides can point to. A standing list for good ideas that are not in this release, so a suggestion can be welcomed without being started. And the habit of attaching time and money to each addition at the moment it is raised, while the trade-off against the launch date is still easy to weigh.
Common questions.
Is scope creep always the client’s fault?
No. It is as often caused by a vague initial scope, an estimate given before the requirements were understood, or a team that says yes in the room and absorbs the extra hours quietly. A specification written as testable statements, plus a change process both sides actually use, protects the schedule regardless of which side a request comes from.
Where it comes up.
BIR E-Invoicing (EIS): What Philippine Businesses Need to Build by 2026
ArticleWhat the BIR e-invoicing system Philippines rollout means for your software: EIS transmission, CAS registration, and what to build before you are covered.
Shipping a Real SaaS in 11 Weeks: The MSP Playbook
ArticleHow to ship a Philippine SaaS in 11 weeks with the MSP playbook: reach your first paying customers without building something you will need to rewrite.
The Case for Fixed-Quote Pricing
ArticleWhy we use fixed-quote software pricing in the Philippines instead of time-and-materials, covering aligned incentives, scope discipline, and hard lessons learned.
Year One Lessons from Running a Software Studio in Cavite
ArticleTwelve months into Blackbyrds Digital. What we got right, what we got wrong, and what we wish someone had told us before we shipped our first commercial project from Silang.
Related terms.
Software Requirements Specification (SRS)
Product & DeliveryA software requirements specification is the written document defining what a system must do: functional requirements as testable statements, non-functional requirements such as performance and access control, plus constraints and assumptions.
Fixed-Scope vs Time-and-Materials
Product & DeliveryFixed-scope and time-and-materials are the two standard ways to price software work.
Discovery Phase
Product & DeliveryA discovery phase is a short, paid engagement that precedes a build and produces the artefacts a build needs: a written scope, user flows, a technical approach, and an estimate grounded in something other than a guess.
Product Roadmap
Product & DeliveryA product roadmap is a sequenced plan of what a product will do next and why, grouped by outcome rather than by feature list.
Scoping a project?
Reading definitions because you are scoping a project? Skip ahead and just ask.