Why the things you find mid-project are the strongest argument for splitting it in two.

The project was a tenancy migration, moving everyone from one Microsoft 365 setup (accounts, mailboxes, files, settings) to another. We’d scoped it to six weeks, signed the statement of work, agreed the cutover weekend. Week three, doing the user-mailbox audit, somebody on the client side mentioned the shared inbox the warehouse team used. Nobody had hidden it; we just hadn’t been told, and it hadn’t surfaced when we’d asked who used what.

Two days later, we found a Microsoft 365 group (a shared workspace tying a mailbox, calendar and files together) nobody was tracking that owned half the project files. The week after that, a third-party booking tool we’d been told was “going away” turned out to be very much not going away, and the calendars it wrote into were being read by the operations team without anyone realising it.

The migration still happened. It happened three weeks late and £6,000 over, and the client was generous about it. That’s what you get when you’ve signed a fixed scope and the discovery work has to keep pretending the scope is fixed.

The shape of the problem

You meet the client. You agree what’s in. You write the statement. You sign it. You start work. Then you find things.

You find a feature in the existing system nobody mentioned. An area of the network that doesn’t appear on the diagram. A connection between two apps that wasn’t on the integration list. A place where the existing setup is doing something useful by accident, and “useful by accident” is the most dangerous kind of useful, because nobody can tell you what it’s for until it stops working.

This isn’t a fault. The client doesn’t know what they don’t know. Half the time the person you’re scoping with has only been at the company eighteen months, and the system was built by somebody who left in 2021. The diagram on the whiteboard is the diagram somebody drew the last time they tried to map it, not the diagram of what’s actually running.

So you find things. And then you have a choice. You can absorb them into the project, take the time and cost hit, and hope you don’t find too many more. Or you can stop, restate the scope, and split the project.

Most of the time, neither side wants to split. The client’s already approved the budget. We’ve already mobilised. Splitting feels like admitting failure. So we plough on, and three weeks later we find another thing, and another, and the project that should have been six weeks is fourteen.

What we should have done

The three projects in the title were all like this: one tenancy migration, one network rebuild, one CCTV-and-access-control consolidation. In each, the discovery phase surfaced enough unknowns in the first fortnight that we should have stopped, written a second statement of work for the things we’d found, and run them in series. Phase 1 was what we knew about. Phase 2 was what we’d discovered.

Instead we ran each as one project. Each ran long. Each ran over. Each landed, but the journey was uglier than it needed to be, and in two of the three cases the client’s internal team got worn down by it in a way that hurts the relationship for months after.

The six would have been: tenancy migration plus AD cutover; network rebuild plus WiFi survey; CCTV head-end refresh plus access-control re-keying. Different teams, different vendors, different sign-offs, but the same client and the same overall scope. The work doesn’t shrink when you split it; the surface area for surprise does, because each phase has a tighter brief and a shorter discovery tail.

If we’d split, the maths would have been kinder. Phase 1 ships on time. Phase 2 starts with a proper scope (the unknowns from Phase 1 are now known) and lands cleanly. Total elapsed time is roughly the same; sometimes a bit longer. But the budget conversation happens once, up front for each phase, not as a running argument across one ballooning engagement.

We don’t split mostly out of inertia. Restating scope mid-flight feels like bad project management, but the real bad project management is pretending the scope is fixed when the ground keeps moving.

A two-week stop-check

We’ve started building a stop-check into the front end of projects that look like they have discovery risk. At the end of week two, or week three on a longer engagement, we hold a structured review. Three questions:

  • What have we found that wasn’t in the original scope? Listed, not waved away.
  • How big is each item? Hours, not handwaves. If we can’t size it, we say so.
  • Does the original scope still make sense, or do we need a Phase 2?

If the answer to the third question is “yes”, we restate. We write a Phase 2 brief, sometimes a paragraph, sometimes a page, and the client decides whether to approve it now, defer it, or roll some of it into Phase 1 and accept a revised timeline for the rest.

The hardest part of this isn’t the meeting but giving ourselves permission to have it. We’re trained to be the firm that delivers what we said we’d deliver, in the time we said we’d deliver it. The discipline is recognising that what we said we’d deliver was based on the picture we had at the time, and the picture changed.

Where this lands with us

This is where our Consulting Services practice does its most useful work, sitting alongside the project, not inside it. A consulting voice that can call a stop-check and restate scope without the political weight of being the delivery team is worth more than its day rate. We’ll do that as a standalone engagement, or build it into a larger project as a named checkpoint.

The principle’s small. If you find things mid-project (and you will), the right answer is usually to split, not to absorb. Two clean projects beat one messy one. The client gets a deliverable on the date you promised. The unknowns get their own scope, their own budget, their own air.

We’re trying to make “let’s split this” a less awkward sentence to say.

If you’re three weeks into a project that’s been running for six and the unknowns are still arriving, the meter is already running against you. Every extra week of absorbed scope costs in three places at once: the budget you’ve already agreed, the team morale on both sides, and the next project the same client was going to give you. The choice isn’t whether to have the conversation, but whether you have it now, while there’s still a clean cut available, or later, when there isn’t.

Working through a project where the unknowns keep stacking up? Drop us a note at info@jmopartners.co.uk. One of us will read it.

JMO|Partners · Enterprise IT, sized for SMEs.