Scoping a ServiceNow Solution – Part 1: Where It All Begins

[CesarM911910837]

If you’ve been following this series, we’ve talked about the inputs a Solution Architect needs and the deliverables they’re expected to produce. Whether it’s a ROM, a proposal, or a full-blown solution plan, one thing is consistent: it all starts with defining the scope.

Sometimes the ask is simple—maybe a quick chat with the client about next steps or prepping for a roadmap discussion. Other times, it’s a full solution plan with architecture, effort estimates, and staffing. Regardless of the size or complexity, scoping is the foundation. It’s how we make sure we’re building the right solution, for the right reasons—and not over-engineering something that doesn’t need it.

Scoping isn’t just about listing features. It’s about understanding the client’s desired outcomes and the challenges they’re facing. And let’s be honest—those aren’t always clearly defined. That’s where the SA steps in, asking the right questions, probing for clarity, and helping the client articulate what success looks like.

In my experience, most scoping efforts have revolved around implementations—whether it’s deploying new ServiceNow applications, integrating with other systems, or building custom apps. Each type of solution has its own nuances, but the goal is the same: define a scope that’s achievable, valuable, and aligned with business goals.

In Part 2, we’ll dig into how to actually build that scope—what to include, how to structure it, and how to make it resonate with both technical and business stakeholders.