Context
A legacy customer portal had accumulated years of technical debt and was limiting the product team’s ability to ship new features. A rebuild was approved with a defined scope and timeline.
Challenge
Mid-project, scope pressure from stakeholders and a vague project name (“the portal project”) made it easy for out-of-scope requests to accumulate. The team absorbed them without flagging the risk, and by the time I identified the pattern, the timeline had been quietly compromised.
Approach
I called the scope problem explicitly in a stakeholder review, re-baselined the timeline with the new scope visible, and introduced a change request process for anything outside the original brief. I also renamed the project to something more specific to reduce the surface area for scope creep.
Outcome
The portal launched successfully. The more important outcome was a change in how I approach project naming and scope definition at the outset. I now establish a change request process and explicit scope boundaries before work begins, not after the problem surfaces.