Como acertar no seu projeto de IGA: comece pelas personas

Why IGA projects fail more often than they should

Identity Governance and Administration (IGA) has been around long enough that you'd expect the failure rate to be low. The concepts are well established, the major platforms are mature, and there's no shortage of people who've implemented them before. And yet projects still overrun, miss their original scope, or deliver a solution that works, just not quite for that organization.

The reasons tend to cluster around a familiar set of themes.

Executive buy-in gets cited a lot, and it does matter. Without senior commitment, projects are vulnerable to being scaled back when budgets tighten or priorities shift.

Program goals are another common culprit: either the aims were set too ambitiously given what the technology can realistically deliver, or they were never precise enough to be measurable in the first place.

Delivery timescales slip when planning is shortchanged in favor of getting something in front of stakeholders quickly. Technology choices go wrong when the evaluation is driven by vendor demos rather than documented requirements. It's easy to be drawn to a feature-rich platform and discover later that the features you actually needed were the ones that need the most customization. Costs overrun when requirements change mid-implementation, or when the effort to configure and integrate is underestimated at the outset.

All of these are real problems, and all of them have been written about at length. But there is one failure mode that tends to sit quietly behind several of the others, and it gets far less attention - the project never properly established who it was building for.

Most IGA projects that struggle can trace at least part of the problem back to assumptions made early on about the types of users, identities, and access scenarios the solution would need to handle, assumptions that turned out to be wrong.

The fix is not complicated, but it does require discipline. It means starting the project by building a complete picture of your identity landscape - not the technology, not the integrations, not the workflows.  Just the people and identities your governance program needs to cover. Everything else follows from that.

The rest of this article explains how to build that picture of your landscape and why doing so makes a bigger difference than most organizations expect.

So, you're looking at Identity Governance

The technology itself is rarely why IGA projects struggle: the root cause is almost always starting with a product instead of understanding your people.

Whether you've been asked to evaluate an IGA platform, or you're already mid-project and things are getting complicated, you've probably noticed that the technology usually isn’t the hard part.

IGA platforms (the software that controls who gets access to what, automates onboarding and offboarding, and ensures someone is reviewing those access rights periodically) are mature, well-understood, and broadly capable. Most of the major platforms will handle the core use cases without much trouble.

So why do so many IGA projects run over budget, take longer than expected, or end up with a solution that doesn't quite fit?

In our experience, it almost always comes back to the same root cause: the organization started by choosing a product rather than understanding its people.

The most valuable thing you can do before evaluating a single vendor is to understand who actually works in your organization and what their relationship with identity looks like.

It's not as simple as 'employees in, employees out'

On the surface, IGA sounds straightforward. Someone joins the company, they get accounts. Someone leaves, those accounts get disabled. In between, someone periodically checks that people still need what they have.

The reality in most organizations is considerably messier. Consider some of the questions that tend to surface once a project is underway:

• What happens to contractors and agency staff - do they appear in your HR system? If not, where does the IGA platform get their details from?
• What about third-party suppliers who need access to specific systems - how are they onboarded, and who manages their lifecycle?
• Do you have employees who work across multiple legal entities or regions, potentially holding different roles in each?
• Are there service accounts, shared accounts, or machine identities that need governing alongside human users?
• What about users in sensitive roles - executives, finance teams, IT administrators - who may need stricter controls or different approval processes?
• Do any of your personas carry access that a regulator or auditor will ask about specifically, and does that change how their permissions need to be reviewed or documented?
• Should permissions last forever or should some permissions, especially sensitive ones, be for a limited time only?

None of these are edge cases. In any organization above a few hundred people, they're the norm. And if your chosen IGA platform hasn't been evaluated against them, you're going to find out the hard way, usually during implementation, when it's expensive to change direction.

Enter the persona

In identity governance terms, a persona is a distinct type of user whose identity lifecycle, access requirements, or data sources differ meaningfully from others: not individual people, but types of people.

There's a technique that's been part of structured systems analysis for decades, borrowed originally from software engineering, which is perfectly suited to solving this problem. It goes by different names - user personas, actors, identity archetypes, but the idea is simple.

Before you define what a system needs to do, you first define all the different types of people (and non-people) that the system needs to serve.

In our experience, a medium-sized organization will typically identify between thirty and fifty distinct identity personas. For organizations in healthcare, education, or retail, that number can easily double.

Some examples to bring this to life:

• A permanent employee joining through your HR system, with a standard onboarding journey, line manager approval, and a defined set of birthright access
• A contractor sourced through an agency, whose record lives in a spreadsheet or supplier portal rather than HR, and who may work across multiple clients simultaneously
• A student or intern with a fixed-term engagement and access that needs to expire cleanly at the end of their placement
• A privileged IT user who holds administrative accounts that need elevated scrutiny, segregation controls, and potentially just-in-time access rather than standing permissions
• A non-human identity, such as an application service account or an API integration, that has permissions, needs governing, and definitely won't be completing a self-service access request form

Each of these personas will interact with your IGA platform differently. Some will be onboarded automatically from a source system. Others will need manual processes or alternative data sources. Some will need specialized approval chains; others will need access to expire on a schedule.

Why this matters for platform selection

Once you have your persona list, your requirements almost write themselves.

You stop asking, “does this platform support joiner/mover/leaver?” (they all say yes) and start asking much more specific questions:

• Can it ingest identity data from multiple sources, such as HRIS, spreadsheets, LDAP, and SCIM endpoints, and reconcile them into a single identity record?
• Can it handle identities that don't have an HR record at all, using a separate onboarding workflow?
• Can it apply different governance policies to different user types, so your contractors get a 90-day access review cycle while your privileged users get monthly?
• When someone changes roles, can it calculate the delta and provision or deprovision the right things without human intervention and without creating orphaned entitlements?
• Can it flag when someone accumulates a combination of access rights that represents a risk, even if each individual right seemed harmless when it was granted?Can it show an auditor why each persona's access was approved and by whom, on a review cadence that matches the risk that persona carries?

A well-designed IGA platform should be able to handle all of the above. The persona exercise tells you which of those capabilities are genuinely critical for your organization, and which are nice-to-haves.

It also tells you what to demonstrate when you're evaluating vendors. Rather than sitting through a generic product walkthrough, you can hand the vendor a set of personas and ask them to show you, specifically, how their platform handles each one.

The persona exercise turns a vendor evaluation from a features comparison into a genuine capability test. It's much harder to obscure a gap when you've asked for a specific scenario rather than a general capability.

What good looks like in practice

When you see a well-configured IGA deployment, the persona thinking is visible in the architecture. Different identity types flow through different onboarding paths. Access is assigned based on role and context, not manually curated lists. When someone's circumstances change (a promotion, a transfer, a contract extension), the platform responds automatically.

Access reviews are scoped intelligently: the right people are reviewing the right entitlements, on a cadence appropriate to the risk level. When a reviewer spots something that shouldn't be there, removal is automatic and auditable. When access is needed urgently, there's a request-and-approval workflow that leaves a clear trail.

Sensitive combinations of access (say, the ability to raise a purchase order and also approve it), are identified proactively, not discovered during an audit. Exceptions are managed with oversight rather than silently accumulated.

None of this requires a particularly exotic platform. What it requires is that someone, early in the project, took the time to understand what types of people and identities the organization actually has, and designed the solution around them.

The payoff shows up everywhere access touches the business: entitlements move faster because they don't need manual intervention, they're more accurate because they're tied to context rather than static lists, and compliance stops being a scramble because the evidence was captured as the work happened, not reconstructed after the fact.

The practical upside

Aside from making your IGA project more likely to succeed, the persona exercise has a couple of useful side effects.

It benefits other projects too. Identity touches almost everything in an organization. Your persona list will be equally useful when evaluating Privilege Account Management (PAM) solutions, endpoint management tools, or anything else that needs to know who your users are and what they do.

It makes stakeholder conversations easier. When you can point to “the contractor persona” or “the privileged admin persona” rather than describing an abstract technical requirement, the conversation becomes more concrete. Business stakeholders understand personas in a way they don't always understand entitlement schemas.

It produces a natural input for project governance. If you use a Responsible, Accountable, Consulted, and Informed (RACI) matrix to manage project responsibilities, your persona list gives you the raw material. Behind each persona sits a business owner, a technical custodian, and a set of stakeholders, all of whom need to be consulted, informed, or directly involved.

Where a platform like Netwrix Identity Manager fits in

None of this is a reason to delay picking a platform. It's a reason to pick one built to work the way your persona list works, not against it.

Netwrix Identity Manager governs internal, external, guest, technical, IoT, and AI agent identities under the same model, so a contractor sourced through a spreadsheet, a service account nobody in HR has ever heard of, an AI agent provisioning its own access, and a permanent employee coming through your HR feed all get the same lifecycle discipline instead of four different workarounds. Third-party and non-human identities get their own lifecycle path, including time-bound access that expires on schedule rather than lingering after a contract or a placement ends. Onboarding new systems doesn't require a bespoke integration project either: standard connectors cover AD, LDAP, SQL, CSV, and SCIM out of the box, with advanced connectors and generic APIs available for anything more specific to your environment. Role management works the same way. You define role and policy models per persona rather than one policy for everyone, and role mining uses machine learning to analyze actual access patterns, discover role structures, and keep the model current as usage changes, so it doesn't just reflect the org chart on the day it was built.

The risk side is built for the same reality. A policy engine detects and prevents segregation-of-duties conflicts, and ongoing monitoring flags orphan accounts and outliers before they surface in an audit instead of after.

None of this replaces the persona exercise. It's what makes rapid design-to-implementation possible: each identity gets defined and governed on its own terms, instead of being forced through a single pipe and patched with exceptions to make it fit. The result is lower risk, faster implementation, and lower cost.

In summary

Identity Governance platforms are mature and capable. The technology is not usually what causes projects to struggle. What causes projects to struggle is starting with a product and trying to fit the organization's reality into it afterwards.

The alternative (identifying your identity personas first, using those to define requirements, and then evaluating platforms against those requirements) sounds obvious when you describe it. But it's surprisingly rare in practice, and the gap it fills is significant.

It doesn't require specialist tooling or deep technical knowledge. It requires time, good questions, and the willingness to involve the right people from across the business early in the process.

Get the personas right, and the rest of the project becomes considerably more straightforward. Get them wrong, or skip them entirely, and you may find yourself retrofitting a solution to a problem you didn't fully understand when you bought it.

Are you having problems with your Identity Program? We can help you understand your personas and how Netwrix Identity Manager can make your project successful. Request a demo.