How We Scope a New Project in the First Week

It's tempting to skip straight to solutions — a new dashboard, a new ticketing system, a new internal portal. The problem is that a tool built on top of an unclear process just makes the unclear process faster. If three people currently handle the same type of request three different ways, giving them a shared tool doesn't fix that; it just means the inconsistency now happens inside one interface instead of three.

Scoping first means we find that inconsistency before it gets built into anything.

It also gives us a way to push back, respectfully, when a requested solution doesn't match the underlying problem. A team might ask for a new reporting dashboard when what's actually missing is a consistent definition of the metric they want reported — building the dashboard first would just make an undefined number look more official.

We start with structured conversations across the team — not just the person who requested the project, but the people who will actually use whatever we build day to day. We're listening for the gap between how a process is described and how it's actually carried out, because that gap is almost always where the real problems live.

Where documentation already exists (SOPs, wikis, old onboarding docs), we read it critically rather than at face value — documentation tends to describe the process as it was designed, not as it has drifted since.

Where it helps, we'll also sit in on the work itself rather than only hearing it described — watching how a request actually moves from intake to resolution tends to surface details nobody thinks to mention in an interview, simply because they've stopped noticing them as unusual.

By the middle of the week, we're usually looking at two pictures side by side: the process as described, and the process as it's actually run. The space between them is where we focus — informal workarounds, undocumented exceptions, decisions that depend on one specific person being available.

We don't propose a final solution, and we don't let the scope expand to cover every adjacent problem we notice along the way. It's common, once you start mapping one process closely, to spot two or three other things that could also use attention — a related workflow, an unrelated reporting gap, a separate tool nobody likes. We note these, but we don't fold them into the current scope.

Keeping the boundary explicit is part of what makes the resulting plan deliverable on a realistic timeline, rather than a list of everything that's ever bothered anyone on the team.

We close the week with a concrete, written scope: what we're going to build or change, what we're explicitly not changing yet, and why. This is also where we flag anything that should be fixed at the process level before any interface is designed — because no amount of good UI design fixes a workflow that contradicts itself.

The result isn't a guess at what might help. It's a plan grounded in how the team actually works, which is also why it tends to survive contact with reality once we start building.