Scope creep is the progressive, uncontrolled expansion of a programme’s scope beyond what was formally agreed in the statement of work, the business case, or the project charter — through the accumulation of additions that were individually small, informally approved, or assumed to be included without explicit agreement. The distinguishing characteristic of scope creep is that it rarely announces itself. It arrives as a series of reasonable-seeming requests: “can we add one more entity to the consolidation,” “can the report include a subtotal we hadn’t planned,” “can we include the subsidiary’s fixed assets in the migration scope.” Each addition seems minor. Collectively they extend the timeline, increase the budget, and shift the programme’s focus from delivery to accommodation.
Why This Matters in GCC and Egyptian Enterprise Programmes
Scope creep is structurally more common in GCC enterprise implementations for two reasons. First, the scale and complexity of GCC conglomerate structures — where an initial programme scoped for a holding company frequently attracts requests to include subsidiary entities mid-programme — creates a constant pull toward expansion. Second, the decision-making structure in family-owned enterprises means that a senior owner’s request to add a new business unit to the implementation scope carries organisational weight that a formal scope change process must accommodate, even when the programme is already in a critical delivery phase. A steering committee that cannot manage scope expansion requests from the sponsoring family’s office is a common source of programme distress in the region.
What Good Looks Like
A well-governed programme has a formal scope change process that applies to every addition — regardless of its source. Every scope change request is documented with: what is being added, why it is being added, the impact on timeline and budget, the impact on already-completed deliverables, and the sign-off required before it is accepted. The steering committee reviews all scope change requests at its regular meeting cadence, not on an ad hoc basis. Accepted scope changes update the programme plan, budget, and statement of work. Informally agreed additions that bypass this process are not accepted as delivery obligations by the implementation team.
What Organisations Get Wrong
The specific decision that most reliably produces uncontrolled scope creep is the steering committee chair — typically the CFO or a group finance director — agreeing to small scope additions directly with the implementation team in working sessions, without routing the request through the formal scope change process. The implementation team, responding to a senior stakeholder, begins work on the addition. The addition does not appear in the programme’s scope register. When the programme is behind schedule and over budget, the analysis reveals a set of deliverables that were never in the original scope, never costed, and never approved through governance — but are now expected to be delivered within the original timeline and budget.
How Loop Wise Solutions Approaches This
In advisory engagements, we establish the scope change process as a programme governance artefact at inception — before the first scope change request arrives. We include scope boundary documentation as a specific section of the programme initiation document: what is explicitly in scope, what is explicitly out of scope, and what the process is for moving items between those categories. In recovery engagements, one of the first diagnostic steps is reconstructing the actual scope — what the team is working on — against the original agreed scope, to quantify the scope growth and establish the basis for a programme reset.
