When organizations begin a major Identity and Access Management (IAM) or Identity Governance and Administration implementation (IGA), most of the early conversation is understandably about technology. What systems need to connect? Where is identity data coming from? How will accounts be provisioned? What does the role model look like? How are access requests, certifications, authentication, and deprovisioning going to work?

Those are important questions. You have to get them right.

But somewhere along the way, usually sooner than people expect, the project begins asking a very different set of questions.

Who actually owns this process? Who gets to decide who should have this access? Why does this approval exist? What does “active employee” really mean? Who is responsible for a contractor after the sponsoring department stops paying attention to them? Why does one department onboard people differently from everyone else?

That is usually the point when an IAM implementation stops feeling like a technology project.

Because it really isn’t one.

At least not entirely.

A large IAM implementation is organizational change, and organizational change is considerably messier than installing software.

IAM Has a Way of Finding Problems That Were Already There

One of the things I have learned through years of IAM implementations is that identity technology is very good at exposing organizational problems.

It doesn’t necessarily create them. Most of the time, they were already there.

Processes develop slowly over the years. A department creates a spreadsheet because there wasn’t another good way to track something. Someone builds a manual approval process because of a problem that happened ten years ago. HR interprets a status one way while IT interprets it another. A business office becomes responsible for something because the person who originally understood the process happened to work there.

Eventually those temporary solutions become permanent.

Then someone decides to implement IGA and automate everything.

Now all of those assumptions have to be explained.

That is where things get interesting.

The documented business process and the actual business process are often two very different things. Sometimes there isn’t a documented process at all. Someone simply knows what to do when an email arrives.

That works until you try to automate it.

An IAM platform needs rules. If an employee reaches a certain status, what should happen? If a student withdraws, what access remains and for how long? If someone is simultaneously a student and an employee, which identity takes precedence? If a contractor becomes an employee, do we create something new or recognize that this is the same human being entering a different relationship with the organization?

The technology can execute those decisions very quickly.

It cannot make the organizational decisions for you.

And that distinction matters.

If HR considers someone active but Information Security believes that person should no longer have access, that isn’t primarily an IAM problem. If nobody knows who owns the lifecycle of visiting researchers, that isn’t an IAM problem either.

IAM simply made the organization confront it.

That can be frustrating during an implementation, but it is also one of the greatest benefits of doing this work correctly. A strong identity program forces an organization to understand itself better.

Be Careful About Automating What You Already Do

One of the most common things I hear early in a project is some version of, “We just want the new system to do what we do today.”

I understand the instinct.

Everyone already knows a major implementation will create change, so maintaining familiar business processes feels safer. There is also a legitimate argument for not trying to redesign every organizational process at the same time.

But there is a problem with simply recreating the existing environment.

You may spend a great deal of money automating a bad process.

So sometimes you have to ask questions that make people a little uncomfortable.

Why does this require three approvals?

Why does someone manually create this account?

Why does this department maintain its own employee list when HR already has the information?

Why does the helpdesk need to contact three departments before resetting a credential?

Why does access remain active for thirty days after someone leaves?

Sometimes there is a very good answer.

Sometimes the answer is, “That’s how we’ve always done it.”

Those are not the same thing.

Institutional history matters, and experienced implementation teams learn very quickly not to walk into an organization assuming every unusual process is wrong. There are often regulatory, contractual, academic, clinical, research, or business reasons for doing something differently.

But those reasons should be understood.

The goal is not to bulldoze every existing process in the name of standardization. It is to separate the processes that still serve a purpose from the processes that simply survived because nobody had a reason to revisit them.

Good IAM implementations automate intentional business processes, not historical accidents.

People Experience the Same Change Very Differently

This is where the human part of the implementation becomes much more important.

Two people can sit in the same meeting, hear the exact same presentation, look at the exact same future-state diagram, and walk away with completely different reactions.

One person sees automation and thinks, “Finally.”

Another person wonders whether automation means part of their job is disappearing.

One department sees centralized governance as long overdue. Another sees it as central IT taking control of decisions they have made locally for years.

Someone who has lived with the pain of the existing environment may want the change immediately. Someone who built that environment and has successfully supported it for fifteen years may understandably feel very differently.

Neither reaction should surprise us.

This is why leadership during a major IAM implementation involves much more than sending project updates.

People need to understand what the change actually means to them.

What decisions will they still make? What work will disappear? What work will change? Who owns the new process? Who supports it? What happens when there is an exception? What happens after the consultants and implementation teams are gone?

These aren’t architecture questions, but they may determine whether the architecture succeeds.

And this is something I have come to believe pretty strongly: ambiguity is usually harder on an organization than a decision people don’t necessarily agree with.

People can adapt to a clear decision. They can argue about it, disagree with it, and eventually figure out how to work within it.

It is much harder to operate indefinitely in a world where nobody knows who is responsible for what. If leadership doesn’t fill that information gap, the organization will. People begin drawing their own conclusions, and those conclusions are rarely helpful.

Identity Governance Is Really a Conversation About Ownership

One reason IAM implementations become organizationally difficult is that identity governance eventually forces conversations about authority.

Who owns identity data?

Who determines whether someone qualifies for access?

Who owns an application?

Who approves an exception?

Who decides when access should end?

Who is responsible for an external identity?

Who reviews access six months later and determines whether it is still appropriate?

These questions sound technical when they appear on a governance chart. In practice, they are conversations about people, responsibility, and sometimes control.

That can create tension.

A department that has created accounts manually for years may feel like IAM automation is taking authority away from them. But automation doesn’t necessarily mean that at all.

The business should still own the business decision. What changes is how that decision gets executed.

A mature model is usually one where the appropriate business owner determines who should receive access and under what conditions, while the IAM platform reliably enforces that policy.

IAM should not become the department that invents every business rule in the organization. Nor should the IAM team become the permanent middleman between every application owner and every user.

The identity platform should take clearly defined organizational policy and execute it consistently, quickly, securely, and audibly.

That is governance.

Then Someone Asks What “Active” Means

What is an active employee? HR may have an answer. Payroll may have a slightly different answer. Information Security may have another. IT may be using an entirely different indicator.

Then try the same conversation with faculty, students, retirees, volunteers, vendors, visiting scholars, affiliates, contingent workers, employees on leave, or someone who is simultaneously an employee and a student.

Now the simple question isn’t so simple anymore. IAM has to take all of these complicated human relationships with an organization and translate them into repeatable policy. That requires discussion. Sometimes quite a lot of it.

Project teams can become frustrated because those conversations appear to slow implementation down. I see them differently. That is the implementation.

If the organization has never agreed on when someone becomes eligible for access, the IAM project has uncovered something that needed to be resolved. If nobody has ever defined when a particular external population should be deactivated, that isn’t a project delay. That is governance work that simply hadn’t been done before.

This is why good identity implementations require participation well beyond IT. HR, Security, Legal, Internal Audit, Student Services, application owners, business units, research organizations, clinical operations and others may all have a legitimate role depending on the organization.

Identity touches almost everything because almost everything eventually asks the same question:

Who is this person, and what should they be allowed to do?

Don’t Let a Green Project Plan Fool You

There is another trap I have seen in large implementations. Everyone becomes so focused on managing the project that they stop managing the change.

The schedule is green. Integration development is green. Testing is green. The steering committee slides all have green boxes. Meanwhile, the people who will actually live with the new environment don’t really understand what is coming.

That isn’t a green project.

A project plan is important, but it cannot tell you whether an organization is ready. Sometimes leadership means slowing something down because an important group isn’t ready or because a business process isn’t understood well enough. Other times leadership means exactly the opposite.

There is a point where collaboration can become endless discussion. Every possible exception gets another meeting. Every decision gets reopened. Nobody wants to be the person who finally says, “This is what we’re going to do.” You cannot run a large IAM program that way either. Listen carefully. Take objections seriously. Change the design when someone identifies something you missed. But eventually a decision has to be made. That is part of leadership too.

Consensus is wonderful when you can get it. It cannot become a prerequisite for progress.

Standardization Matters, but So Does Reality

IAM programs usually create some degree of centralization, and that is generally healthy. You want consistent governance. You want common identity data. You want standardized lifecycle processes. You don’t want twenty departments independently deciding how identities should be created and removed. But centralization can become lazy if we aren’t careful. Not every difference is dysfunction.

A medical environment may have requirements the rest of the organization does not. Research environments may operate differently because of collaboration requirements. Universities have populations and lifecycle relationships that look nothing like those in a typical corporation. A government agency may have regulatory requirements that legitimately demand a different process.

The goal should not be uniformity for the sake of uniformity. Standardize what should be standard. Accommodate what legitimately needs to be different. And know the difference.

That last part requires experience and judgment, which is why the human element never completely disappears no matter how sophisticated the technology becomes.

Give the Team Permission to Tell You Something Isn’t Working

Large programs get messy. Something will not work the way everyone expected. A data assumption will be wrong. Testing will uncover an edge case. A workflow that looked perfectly reasonable on paper will annoy everyone who actually has to use it. Someone will discover that a source system behaves differently during a job transfer than anyone realized. That is normal.

What matters is whether the team feels comfortable saying it.

One of the worst environments a leader can create is one where every project meeting has to sound positive.
People need to be able to say, “This isn’t working.”

They need to be able to say, “I think we designed this wrong.”

And sometimes they need to be able to say, “I don’t know.”

Those are not signs that the implementation is failing. Quite often, they are signs that people are doing the work seriously enough to uncover the problems before production.

I’d much rather have an uncomfortable conversation during design than discover the same problem six months after go-live. That requires leadership that doesn’t punish bad news.

Leading Through This Work Can Be Exhausting

There is also a side of organizational change that we rarely talk about in technical circles. It can simply wear people out.

The people leading these programs are often maintaining the current environment while building the next one. They are explaining technical issues to executives, organizational concerns to technical teams, and executive decisions back to everyone else.

They are negotiating between departments, keeping implementation teams moving, answering questions, resolving disagreements, dealing with unexpected problems and trying to maintain confidence in the program while knowing perfectly well that not everything is figured out yet. Some days you handle that extremely well. Some days you don’t. That’s reality.

Leadership during a major organizational transition is not about pretending you have every answer. It is about creating enough stability that people can continue moving while the organization works through the questions.

Sometimes that means saying, “This is the decision.”

Sometimes it means saying, “We need more information.”

And every once in a while it means saying, “We got that wrong. Let’s fix it.”

I’ve gained more respect for that last sentence over the years.

Your IAM Platform Should Not Make Organizational Change Harder

All of this is also why technology choice matters so much.

Your organization is already going through enough change during an IAM implementation. The product should not introduce unnecessary change simply because it cannot support the way your organization legitimately needs to operate.

And it certainly shouldn’t require layers of custom code, scripts, middleware, and bolt-on applications just to accommodate normal organizational complexity.

That philosophy has been central to Fischer Identity for more than 25 years.

Fischer Identity has spent those years working in some extremely complicated identity environments, including organizations with multiple authoritative sources, overlapping identity populations, complicated lifecycle relationships, regulatory requirements, external users, dynamic access policies and large-scale organizational change.

The platform was built around configuration rather than customer-specific customization. That distinction becomes especially important when the organization changes again, because it will.

At the University of Virginia, for example, Fischer Identity was implemented across an extraordinarily complex environment that included an R1 research university, academic medical center, regional trauma center and healthcare operations, employees, faculty, students, affiliates and other populations. The implementation replaced legacy identity processes and significantly modernized onboarding, lifecycle management, identity matching, provisioning and deprovisioning.

Then, only six months after the new identity platform went live, UVA consolidated three HR systems into Workday HCM. That could easily have become another major IAM redevelopment effort. Instead, the change was handled through configuration: disconnecting the legacy sources, aligning the identity logic with Workday and testing the resulting processes with the appropriate teams. This proved itself again when UVA implemented Oracle HCM only a few years later for their healthcare operations. The additional source system was only a simple configuration update.

That is what a sustainable identity architecture should allow you to do, accommodate organizational changes.

Leadership changes. Systems change. HR platforms change. Business processes change. Regulations change. Acquisitions happen. New populations appear. New applications arrive.

The IAM platform has to be able to move with the organization rather than become the reason the organization cannot move.

Experience Changes the Way You Approach These Programs

One of the things I appreciate more today than I did earlier in my career is the value of people who have actually lived through large organizational change.

They usually talk about it differently. There is less theory.

They know that a governance model can look perfect on a slide and fall apart when it meets organizational culture. They know that a process everyone agreed to in a conference room may behave very differently when hundreds of people start using it. They know that sometimes the technically elegant answer is not the operationally sensible one.

They also learn when to push and when to listen. That experience is difficult to manufacture.

Fischer Identity is somewhat unusual in this industry. We have been doing this for more than two decades, but we have never tried to become the loudest company in the market. We don’t spend millions trying to create the impression of expertise through marketing. We have invested heavily in the product, our people, and the customers who depend on us.

That has made Fischer something of an underdog in a market filled with much larger names.

We’re comfortable with that.

Because when an organization is sitting in a room trying to figure out how an employee who is also a student, contractor, researcher and former affiliate should actually be governed, marketing doesn’t solve the problem.

Experience does.

IAM Transformation Is Organizational Transformation

If I could tell a leader beginning a large IAM or IGA implementation one thing, it would be this:

Don’t underestimate what you are about to change. You may think you are replacing an identity platform.

You are probably going to touch HR processes, onboarding, offboarding, security policies, application ownership, data quality, access approval, helpdesk operations, compliance, departmental authority, employee experience and long-standing business practices.

You are also going to uncover some disagreements that have been hiding quietly inside the organization for years. That’s not necessarily a bad thing.

Handled well, an IAM implementation can leave an organization with much more than better technology. It can create clearer ownership, better business processes, stronger governance, cleaner data, faster onboarding, more reliable deprovisioning and a shared understanding of how access decisions should actually be made.

But getting there requires something beyond technology.

It requires patience without becoming passive. Empathy without avoiding difficult decisions. Confidence without pretending to know everything. And enough humility to change direction when the organization teaches you something you didn’t know when the project began.

The technical implementation matters. The people living through it matter more.

And long after everyone has forgotten the project plan, they will remember how the organization handled the change.