Managing Scope Creep with Clients: A Single-Vendor Platform Becomes Multi-Vendor Mid-Build

The platform was built as single-vendor. Partway through, the client changed the requirement to multi-vendor: institutions and individual teachers each needed their own profile and the ability to sell courses through the platform. That is not a feature request, it is a different platform underneath the same brief. I was Associate Project Manager at the time, still inside my provisional period.

A scope change reads differently from scope creep the moment you size it. This was not several small asks that add up: it was one structural change that touched the data model, the checkout flow and the account system at once. I treated it as a re-scoping conversation, not a change-request queue.

I went to the client with the size of the change and asked for more time. They declined: the launch date mattered more to them than the schedule did. What they offered instead was budget, which meant the real constraint was not the added scope, it was the calendar. That reframed the problem: I could not buy time, so I had to buy capacity inside the time that already existed.

I brought new developers onto a project that was already underway, which is normally the expensive move: a new person costs the team that trains them before they add anything back. I decided to split the work instead of splitting it evenly: the developers already on the project, who already carried the context, took the foundation work that depended on it. The new developers took the frontend implementation against a plan that did not require that context to execute. That kept the training cost close to zero.

The sprints were rearranged to carry the increased scope inside the remaining timeline. The developers already on the project built the foundation: the parts of the multi-vendor change that touched what they already understood about the platform. The new developers implemented the frontend against the plan the existing team had laid out, working from a defined plan rather than from the platform's history.

The original delivery shipped on date. Phase 2 (the multi-vendor work) shipped after it. The client rated the engagement 5 stars, added a bonus on top of the contract, and chose the same team for their next project.

Adding people to a late project costs exactly what it is reputed to cost, if you add them to the part of the work that needs context they don't have. It does not cost that if you route them to the part that does not need it. That split was the decision, not "we added more developers." I look for that seam now before I bring anyone new onto a project already underway.