There's a pattern I've seen repeat itself across identity engagements of every size — from a single-domain Active Directory cleanup to a full Entra ID migration for a global enterprise. The project starts with energy and optimism. The stakeholders are aligned. The technology is well understood. And then, somewhere around week three, everything starts to slow down.
Not because the engineers can't execute. Because nobody agreed on what "done" actually meant.
After many years of delivering identity and security solutions to enterprises and government clients, I've come to believe that the most valuable thing an identity architect can do isn't configure a system or write a provisioning script. It's have the conversation that nobody else in the room is having — before a single line of configuration is written.
This is that conversation.
Why Identity Is Uniquely Hard to Scope
Most technical projects have clear edges. You're building a thing. You either built it or you didn't.
Identity doesn't work that way. Identity touches HR (who gets an account), IT (how it's provisioned), Security (what they can access), Compliance (what gets logged), and every application team that has ever bolted on a login screen. It's not a project — it's infrastructure that sits underneath every other project.
That cross-cutting nature creates two scoping problems that don't exist in most engagements:
First, clients often don't know what they have. I've walked into environments where the authoritative source of user data was a spreadsheet someone maintained manually. I've seen organizations where three different teams believed they owned identity — and none of them were fully right. Discovery isn't a pre-project phase you can skip. It is part of scope, and it needs to be treated that way.
Second, the people who approve scope aren't always the people who understand the technical implications. A CISO who signs off on "migrate our users to Entra ID" may not realize that the phrase "our users" includes seventeen application service accounts, six external partner directories, and a legacy HR system that only speaks LDAP over port 389. The gap between what leadership thinks they're buying and what engineering knows they're building is where projects go sideways.
Good scoping closes that gap before it opens.
Five Questions Before Anything Else
When I take on an identity engagement, there are five questions I ask before I open a design document or touch a single configuration setting. The answers don't just inform the scope — they often reveal whether the client is ready to begin at all.
1. What problem are you actually trying to solve?
This sounds basic. It isn't. Clients come to identity engagements with stated goals — "we need to modernize our directory," "we need SSO," "we need to be zero-trust ready" — that often obscure the real driver. Press on it. Is this driven by a compliance audit? A recent incident? An M&A event that's forcing a forest merger? A departing employee who still has access? The underlying driver shapes everything: timeline, risk tolerance, what success looks like, and what failure costs.
2. Who owns identity today — and who thinks they do?
In most organizations, identity ownership is assumed rather than assigned. IT manages Active Directory. Security owns the access control policies. HR controls the data that feeds provisioning. Nobody owns the intersection. Find the actual decision-makers — the people who can approve a change, absorb a risk, or block a rollout — before you build anything that depends on their cooperation.
3. What's your authoritative source of truth for users?
This is where I spend more time than clients expect. Is it the HR system? Active Directory itself? A home-grown identity store? Does it cover contractors, service accounts, external partners, and shared mailboxes — or just full-time employees? The answer determines almost everything downstream: what gets automated, what gets migrated, and what gets cleaned up manually.
4. What does "done" look like to your stakeholders versus your technical team?
These two answers are almost never identical. Leadership defines done as "users can log in and we passed the audit." Engineering defines done as "all legacy authentication protocols are disabled, conditional access is enforced, and privileged access is reviewed quarterly." Both definitions are valid. Neither is complete without the other. Write them both down, and make sure both groups see each other's version.
5. What's your tolerance for disruption?
Some clients can absorb a weekend of downtime. Others will escalate over a two-minute MFA prompt they didn't expect. Knowing this early isn't just about managing expectations — it dictates the migration strategy, the rollback plan, and how aggressively you can move.
The Three Scope Traps
Even with good answers to those five questions, experienced practitioners know there are failure modes that show up in nearly every engagement. I think of them as scope traps — situations that look reasonable on the surface but reliably cause projects to expand, slow down, or stall.
The "just migrate us" trap. This is the most common one. The client wants to move from Point A to Point B, but they've never defined what Point B looks like. What's the target architecture? What's the target access model? What stays on-premises and what moves to the cloud? Without answers to those questions, every design decision becomes a negotiation, and timelines stretch indefinitely. The fix is a High-Level Design phase that forces target-state decisions before implementation begins — and holds stakeholders accountable for approving it.
The "clean it up" trap. A client asks you to "clean up" their directory as part of a migration or assessment engagement. This sounds simple. It isn't. Does "clean up" mean disable stale accounts? Delete them? Remediate group membership? Fix naming conventions? Remove legacy GPOs? Reconcile service accounts with no documented owners? Each of these is a real project of its own, and without an explicit definition of scope, the work expands to fill whatever time is available. Establish clear criteria for what "clean" means — and document what's explicitly out of scope — before you start.
The "while you're in there" trap. This one is the most dangerous because it usually comes from well-intentioned clients who are genuinely trying to be efficient. You're already touching the provisioning pipeline — can you also handle the contractor lifecycle? You're rebuilding the group structure — can you also set up Privileged Identity Management while you're at it? Each individual request is reasonable. Collectively, they add weeks to the engagement and dilute focus. The answer isn't always no, but it always needs to be a documented change order that resets timeline and resource expectations.
What a Good Scope Document Actually Contains
A scope document isn't a statement of work. It's a shared understanding of what the engagement is and isn't — written in language that both the client's leadership and the technical team can hold each other accountable to.
At minimum, it should contain:
- Explicit boundaries: What is in scope, and — just as importantly — what is explicitly out of scope. Both need to be named.
- Assumptions and dependencies: What has to be true for this engagement to succeed? What systems, teams, or decisions does the work depend on that are outside your control?
- Discovery deliverables vs. implementation deliverables: Discovery produces findings and recommendations. Implementation produces configurations and migrations. Treat them as separate phases with separate sign-offs.
- Escalation triggers: What circumstances would cause a change to scope, timeline, or cost? Define them proactively so that when they occur, the response is a process rather than a crisis.
- Keep goals reasonable: Create a roadmap, or better an identity program, for ongoing extension of services and continous improvement.
The best scope documents I've produced started as design decision logs — living documents that capture every significant architectural choice, the options considered, and the rationale for what was selected. When a client later asks "why did we do it this way," the answer is already written down.
Scope Is a Trust Document
Here's the thing that took me years to fully internalize: a well-scoped engagement protects the client as much as it protects you.
When scope is vague, clients absorb the downside. They end up with an engagement that runs long, costs more than expected, and delivers something that doesn't match what they imagined. They don't always know why — they just know the project didn't go the way they hoped.
When scope is clear, clients can make informed decisions. They can prioritize what matters most, defer what can wait, and hold both sides accountable for delivering what was agreed. That's not a vendor protection mechanism. That's professional practice.
The practitioners who build long-term client relationships aren't the ones who say yes to everything. They're the ones who arrive with questions, listen carefully, and help the client understand what they're actually signing up for — before anyone starts configuring anything.
That conversation is where real advisory value lives.
No comments:
Post a Comment