If you work in higher education, healthcare, or the non-profit sector, you’ve likely faced this reality: launching an Identity and Access Management (IAM) or Identity Governance and Administration (IGA) program is rarely as simple as drafting a project plan and assigning a go-live date. It’s not because your project managers aren’t capable. It’s because IAM isn’t just a project—it’s a business transformation.

Too often, organizations assume that IAM can be initiated the same way as other IT infrastructure upgrades: select a vendor, assign a PM, and let the waterfall begin. But when it comes to IAM and IGA, that approach almost guarantees failure.

IAM Is Not Just IT’s Responsibility—It’s the Business’s Problem to Solve

Your IAM system governs who has access to everything—from student records to patient charts, from research grants to donor databases. The complexity of your environment isn’t just technical. It’s functional, operational, and deeply tied to how your institution or organization delivers its mission.

So why do many IAM implementations struggle? Because they begin in reverse.

Instead of identifying the problems IAM is supposed to solve, teams start by drafting project plans, selecting vendors, or building timelines. That’s like hiring a builder before you’ve drawn the blueprint—or even decided what kind of house you want.

You Can’t Plan What You Don’t Understand

An effective IAM program doesn’t start in the PMO. It starts with the IAM team sitting down and asking:

• What are all the identity-related pain points we experience today?
• Where are we spending time manually managing access?
• Which compliance, audit, or security risks are keeping us up at night?
• What do we wish our IAM platform could do?

This is the true foundation of your future IAM program. Not the project schedule. Not the Gantt chart. But a deep, honest assessment of where things are broken and how they impact your operations, your people, and your risk posture.

Step One: Identify and Prioritize Pain Points

Your IAM team must conduct internal discovery before anyone starts writing a project plan. This means:

• Gathering input from helpdesk staff, IT, HR, academic affairs, research, compliance, and clinical leadership
• Documenting where lifecycle processes fail—onboarding, offboarding, provisioning delays, access reviews, etc.
• Recognizing technical debt—manual workarounds, custom scripts, lack of integration with source systems
• Listing features the current solution lacks—or worse, requires constant patching or is end of life
• Identifying risks—duplicate identities, orphaned accounts, or users with excessive access

Once you’ve gathered this data, score and prioritize it based on business risk, impact, and urgency. This becomes your IAM requirements catalog.

Step Two: Estimate the Level of Effort

With your use cases and goals in hand, you can now define the scope:

• How many user types are involved?
• How many systems must be integrated?
• Do you need to manage non-employee identities like adjunct faculty, visiting nurses, or volunteers?
• Will you handle MFA enrollment, remote identity proofing, or delegated access?

This scoping process helps quantify the level of effort—which is exactly what the project manager needs to build a realistic project plan.

Now the PM has something solid to work with: business-aligned objectives, clearly defined use cases, and a right-sized understanding of complexity.

Step Three: Let the Project Plan Support the Vision—Not the Other Way Around

Too often, organizations assign a project manager before the IAM team has scoped the problem. The result? The PM builds a timeline based on assumptions, not aligned goals. Then the project gets bogged down with scope creep, missed deadlines, and stakeholder frustration.

The fix? Reverse the flow.

Let your pain points shape your requirements, which inform your project scope, which then becomes the project plan.

This approach keeps your IAM program anchored in reality—and aligned to real business needs.

Start With the “Why,” Not the “When”

IAM and IGA projects don’t fail because of bad intentions—they fail because they’re treated like just another IT upgrade.

If you work in education, healthcare, or the non-profit world, your IAM system isn’t just technical infrastructure—it’s mission-critical infrastructure. And that requires a different planning approach.

• Start with business problems
• Prioritize the real pains
• Scope the true effort
• Then—and only then—write your project plan

At Fischer Identity, we specialize in helping organizations get this process right from day one. If your team is thinking about starting (or restarting) an IAM journey, we’d love to be part of the conversation.

Contact us to learn more about how to launch a truly successful IAM program.