I recently came across a social media debate that perfectly captures a dilemma we face in the IAM community – where exactly does the line sit between partial success and partial failure? Practitioners rarely agree on when a project actually crosses the finish line as a success. And this is the question I am going to take a closer look at today.
To clarify the scope, my analysis focuses on deep IAM and Identity Governance and Administration (IGA) deployments – specifically complex platforms like One Identity Manager – rather than standard Single Sign-On (SSO) or basic access tools like Microsoft Entra.
In my experience, true identity management project delivery success means client satisfaction at the tail end of the deployment, backed by clear business value. The platform must deliver faster, better processes. For example, shorter onboarding times, smoother compliance audits, and more integrated applications.
In a nutshell:
- IAM project success isn’t measured at go-live – it shows itself months later in role stability, process discipline, and team capability.
- The biggest failure trigger is skipping a dedicated discovery phase and budgeting based on assumptions. Clean data almost never exists.
- Use the 80/20 rule: fully automate the standard 80% of daily lifecycle events, and use semi-automated notifications for the complex 20%.
- Budget two full months for UAT – not two weeks. Complex scenarios only surface during real-world testing.
- The right IAM partner isn’t one who agrees to everything – it’s one willing to say ‘no’ to customization that adds maintenance burden without business value.
Defining IAM project success – why practitioners rarely agree
I have been in the IAM space long enough to know that project success is highly subjective, and the definition changes depending on the engagement model.
Success in staff augmentation vs. full identity transformation
When a client hires my team simply for extra hands on deck – as pure staff augmentation – success is straightforward. We deliver the requested labor, the client remains satisfied, and they pay the invoice.
But a true identity transformation requires a completely different benchmark. I cannot measure this type of success on the day of go-live. Instead, I evaluate the implementation months or even a year down the road to see how the platform actually operates.
The three signs of long-term IAM success
A successful identity management project delivery reveals itself through long-term operational health:
- Role stability. Does the client maintain clean, structured roles, or does the team constantly create ad-hoc exceptions?
- Process discipline. Does the organization follow the designed workflows, or did we build the system on unrealistic expectations that everyone now bypasses?
- Team capability. Did the client build a competent, dedicated internal team to run the platform?
A common, critical mistake is to buy a complex IGA tool and assume a single system administrator who previously managed Active Directory can run it alone. This approach fails, pretty much always.
The most common reasons IAM projects fail
In major deployments, failure rarely comes from a single catastrophic mistake. It accumulates from predictable issues that most organizations recognize too late:
- No dedicated discovery phase – budgeting before understanding the actual environment
- Dirty HR data discovered too late (e.g. “AD_Group_0015” with no designated owner)
- Assembled teams of strangers instead of cohesive, collaborative units
- Trying to automate 100% from day one instead of starting with an MVP
- Underestimating UAT – allocating two weeks instead of two months
- Leadership expecting ROI on every feature immediately after go-live
- Stakeholder resistance – bypassing designed workflows or rejecting process change
- Ignoring non-human identities – service accounts, APIs, and AI agents left out of scope.
Skipping the discovery phase
Many organizations skip a dedicated discovery phase and go straight to budgeting. That’s little more than an educated guess. Estimating the exact effort before a thorough discovery is incredibly difficult, and those estimates almost always miss what’s actually hiding in the environment.
Assumptions vs. reality: when clean data doesn’t exist
Typical project agreements assume the client will provide clean HR data, assign system owners, and organize internal stakeholders before the implementation begins. Many consulting firms treat these clauses as legal shields. If a deadline slips or the budget runs over because the client failed to meet these prerequisites, these vendors simply point to the contract, secure in their legal coverage, and charge for change requests.
I take a different approach. I actively discuss these critical IAM project management success factors with the client on day one.
For example, clients often begin to clean their data just two weeks before the scheduled launch. They quickly discover thousands of Active Directory groups with names like “AD_Group_0015” that have no designated owner. Locating those owners and cleaning that data can easily take six months. When this happens, the entire project grinds to a halt.
Cohesive teams vs. paper experts
Ultimately, the people on the project dictate the outcome. My practice relies on a tight-knit, internal team of experts with proven, collaborative experience.
In contrast, large consulting firms frequently assemble a group of strangers specifically to staff a new contract. They select people based on impressive resumes. However, fifteen years in IT looks excellent on paper but guarantees absolutely nothing if the individuals cannot deliver as a cohesive unit. These assembled collections of contractors represent a massive risk, and they fail far more often than structured, experienced teams.
How to plan an IAM project that doesn’t fail
Start with measurable business goals, not security slogans
Many organizations kick off an IAM initiative because they want better security. That’s a reasonable goal, but it doesn’t make a strong business case. Security alone isn’t measurable, and if you can’t define success before the project starts, you won’t know whether you’ve achieved it.
From my experience, successful IAM project management success factors start with specific business problems. You can ask questions like:
- How much do we want to reduce employee onboarding time?
- How many manual provisioning tasks should we eliminate?
- How much faster should access requests or offboarding become?
- How will we measure fewer security incidents caused by excessive access?
These objectives give everyone a shared definition of success.
Run a dedicated IAM assessment before budgeting
Build an initial budget, but make it clear that it’s preliminary. Once you’ve analyzed the current identity landscape, application inventory, business processes, and technical constraints, you can produce a more realistic implementation plan. That estimate may increase by 20%, 50%, or even more, but that’s far better than committing to unrealistic expectations that will derail the project later.
Deliver an MVP first: JML + critical applications
Many organizations try to deliver every IAM capability – provisioning, certification campaigns, access reviews – in a single implementation. That approach rarely works.
Instead, I recommend delivering a focused MVP first. In many projects, that means implementing the Joiner, Mover, Leaver (JML) lifecycle together with identity provisioning for a limited number of critical applications (often around ten). Once the platform proves its value, you can expand into access reviews, certification campaigns, additional integrations, and more advanced governance capabilities.
The 80/20 rule for automation
When planning the IGA implementation timeline, trying to automate every single edge case from day one is a recipe for project delays. I always advise clients to apply the 80/20 rule, especially when building a Minimum Viable Product (MVP).
We prioritize automating the standard 80% of daily transactions and handle the highly complex, rare exceptions differently.
The 80/20 automation strategy
| Process Phase | Automation approach |
| The standard 80% | Full automation. Standard joiners, lateral movers, and standard terminations execute instantly without human intervention. |
| The complex 20% | Semi-automated notifications. Instead of spending weeks programming a highly complex automation for a rare scenario, we automate the detection of the event and trigger a notification requesting manual intervention. |
This hybrid approach keeps the project moving. If a client is not operationally ready for fully automated decision-making on complex exceptions, we do not force it. Instead of manual spreadsheets, we use the system to flag the exception and assign it to a human owner. This strategy is one of the most critical IAM project management success factors, which keeps the initial launch simple, clean, and on schedule.
Phased IAM means more time to build experience
An ideal scenario is when an organization gradually takes ownership of application integrations, while the implementation partner continues to provide guidance and quality assurance. That creates a much more sustainable identity management project delivery model than handing everything over at the end of the project.
Don’t underestimate the complexity hiding beneath the surface. Modern IAM projects extend beyond employee identities and also cover:
- service accounts
- APIs
- AI agents and other non-human identities
Currently, they often represent a significant portion of the identity ecosystem, but many business cases barely acknowledge them. The same applies to application integration. Legacy applications and decades of technical debt can dramatically change the implementation effort.
The earlier you identify these complexities, the more realistic your roadmap becomes.
Why every successful IAM project starts with an assessment
An IAM assessment answers the question: what does your identity environment actually look like today?
Before you automate anything, you need a clear understanding of your systems, data, and processes. Otherwise, you’ll build workflows around assumptions.
What an IAM assessment covers – step by step
You start off with inventorying systems and business processes. Then, you run a review of your HR data, Active Directory, access policies, and the roles that exist. This lets you understand how identities move through the organization.
From there, map out the entire user lifecycle. This means covering all the steps from onboarding and access provisioning to role changes and offboarding, to identify any potential inconsistencies and bottlenecks.
Of course, most organizations don’t start from scratch. Many already have someone internally who has researched IAM and defined a target state before bringing in someone to handle the implementation itself.
In those cases, the role of an experienced IAM implementation partner is to validate the assumptions, identify any gaps, and make sure the implementation reflects the organization’s real environment.
What standardized identity lifecycle (JML) processes look like in practice
In theory, every organization has a policy for managing how employees enter, move through, and exit the company. The Joiner-Mover-Leaver (JML) process defines this identity lifecycle. Unfortunately, in practice, these JML processes often exist only on paper.
A mature, well-functioning identity lifecycle must be standardized, automated, and highly resistant to ad-hoc workarounds. When I evaluate an organization, I look at the operational backbone. True stability relies on practical tools like RACI charts (Responsible, Accountable, Consulted, Informed), gap analysis templates, and rigid process templates. These tools turn abstract security policies into a repeatable, daily reality, which directly impacts the overall identity management project delivery.
What to look for in an IAM implementation partner
A good IAM implementation partner should be accountable for more than just technicalities. Look for a team that:
- Communicates openly and flags risks early.
- Helps set priorities instead of trying to tackle everything at once.
- Acts as an advisor and not only an implementation team.
- Challenges unnecessary customization instead of agreeing to every request.
- Focuses on long-term maintainability, not just getting the project over the finish line.
For reference, one of the smoothest projects I’ve worked on succeeded because both sides worked as partners. We discussed risks early, agreed on priorities, and had open communication throughout the implementation.
It was a two-way street, because the client also trusted our recommendations instead of treating us purely as extra hands. That allowed us to solve problems before they turned into blockers.
If I were to add something unorthodox to the list above, I’d say that another good indicator of the right partner is their willingness to say “no.”
I often advise clients against customizing IAM processes unless there’s a strong business reason. The more exceptions you introduce, the harder the solution becomes to maintain, extend, and upgrade.
I remember one project where a client wanted to use a built-in SCIM connector for Workday while also heavily customizing the data after it arrived. At that point, the standard connector added very little value because the custom logic became the real implementation. We recommended simplifying the underlying process instead. The client decided against it because there wasn’t enough time to change the business process, which ultimately made the solution more complex.
The best implementation partners explain the trade-offs and push back when necessary. You might not like their answer in the given moment, but that’s the aspect that influences successful identity management project delivery over the long term.
Why the human layer decides IAM success more than the technology does
This is, arguably, the most heated topic on IAM-related forums. And I understand why, because technically sound IAM projects often struggle when the organization isn’t ready for the change. This exposes that, right next to the more apparent technical gap, companies are also struggling with organizational ones. As one Redditor said, “people make or break an IAM program“.
Successful identity management workshops don’t end with everyone agreeing. They end with clear goals, a phased implementation plan, documented assumptions, and risks that every stakeholder understands.
The other critical factor is ownership. IAM involves application owners, business sponsors, IT, the help desk, and leadership. Everyone plays a role, and everyone needs to understand their responsibilities before the project starts.
Not everyone, though, feels confident about this straight away. Some stakeholders remain convinced their way of working is the right one, even after you’ve explained the trade-offs. If escalation doesn’t help, I document the risk, assign it to an owner, and make sure everyone understands the potential impact. A clear email stating, “We believe there’s a high chance this will cause problems,” prevents anyone from saying later, “Nobody warned me.”
Interestingly, those conversations often change people’s minds. Once the risk is documented and visible to leadership, stakeholders become more willing to compromise or move their requirements into a later phase. If they still choose to accept the risk, that’s their decision, but it should always be an informed one.
If you’re responsible for defining IAM and IGA ownership at your organization, our guide on access management responsibilities is a useful starting point.
Why organizations underestimate IAM complexity – and how to fix it
Because acquiring a modern Identity Governance and Administration (IGA) platform requires a major capital investment, leadership teams naturally expect an immediate return on investment. They buy a comprehensive platform and want to utilize every single feature from day one.
While this expectation makes financial sense on paper, it completely ignores the operational reality of identity management. No matter how mature an internal security department is, these projects are highly complex. They involve a massive web of stakeholders, misaligned business processes, and endless variables. Trying to roll out every feature simultaneously is like jumping straight into the cockpit of a Formula 1 car without a driver’s license. At best, it spikes organizational anxiety; at worst, it leads to a catastrophic project crash.
To prevent this, managing expectations around the IGA implementation timeline must start before signing the contract.
Managing timeline expectations – the UAT reality
Interestingly, in my day-to-day practice, I rarely meet clients who insist on a big-bang launch. Most business leaders actually prefer a phased rollout because they want to demonstrate quick wins to their board.
However, where clients do underestimate the timeline is in the depth of each phase – specifically when it comes to testing.
Early in my career, I might have allocated a standard two weeks for user acceptance testing (UAT). Today, I routinely budget two full months. The technical implementation of a connector is rarely the bottleneck; the real challenge lies in the sheer volume of real-world business scenarios that require validation.
Basic vs. comprehensive testing: what actually gets caught
| Testing focus | Basic “paper” testing (what fails) | Comprehensive real-world testing (what succeeds) |
| User provisioning | Verifying if an account successfully creates or locks in Active Directory. | Simulating a worker going on parental leave, returning, changing departments, and then transferring back to the original team. |
| Delegation | Verifying if an approval button works. | Verifying if system access requests automatically route to a designated backup approver while a manager is on vacation, and revoking that backup access upon their return. |
I once worked on a major project where the client approached testing with exceptional discipline. They mapped out over one hundred highly specific, complex test cases covering maternity leave, rapid department transfers, and operational exceptions.
Testing at this level requires active participation from multiple business departments, not just IT. Skipping this step or rushing UAT to meet an artificial deadline guarantees that those untested edge cases will break in production, damaging user trust and stalling adoption. True success requires slowing down during the testing phase to ensure the system survives real-world chaos.
Go-live is not the finish line – treating IAM as a living system
The real test for your IAM implementation comes afterward, as the organization becomes more comfortable with the platform and its processes.
That’s why we prefer a phased approach at QWEY. Companies rarely want to introduce every process from day one, and that’s a good decision. Instead, we design the solution so additional capabilities can be enabled later without redesigning the entire platform.
I’ve seen this careful approach when it comes to account deprovisioning. Some organizations initially prefer to disable accounts when someone leaves rather than delete them permanently. We build the process with both scenarios in mind, leaving permanent deletion turned off. After a few months, once the client has confidence in the process, they often decide to enable it.
The same applies to applications and business processes. During the initial IGA implementation timeline, a client may decide that certain systems don’t need to be included yet. As the business changes or new priorities emerge, they can gradually expand the platform without starting from scratch.
That’s why I recommend treating IAM and IGA as living systems. New applications will appear, business processes will evolve, and organizational priorities will change – that’s an inevitable part of tech.
Ready to plan your IAM project the right way?
Ultimately, successful identity management project delivery depends on transparency and early risk management. Don’t assume your internal data is clean, processes are flawless, and your timelines are simple. Start with a rigorous, honest discovery phase – that’s where the most resilient projects begin.
True IAM project management success factors run deeper than technical integration. You must set clear, value-driven goals, commit to thorough testing, and secure realistic budgets that account for inevitable unknowns. Real success proves itself months after launch, when your organization smoothly runs the platform and maintains clean, stable roles.
Every successful IAM implementation starts the same way: with an honest assessment of your current identity environment – before any budgeting or scoping. Contact our team to discuss a discovery phase tailored to your organization. We’ll tell you what we find, what it will take, and – if it doesn’t make sense – we’ll tell you that too.
FAQ – IAM project management
Why do IAM projects fail?
Most IAM projects fail because of organizational issues, not technical ones. The most common causes are: skipping the discovery phase, starting with dirty HR data, assembling teams without collaborative history, and trying to deliver all capabilities at once instead of phasing the rollout.
How long does an IAM implementation take?
Timeline varies significantly by scope. The technical implementation of connectors is rarely the bottleneck. UAT alone should be budgeted at two full months for complex environments. Budget estimates based on assumptions – without a discovery phase – often need to increase by 20–50% once the real environment is analyzed.
What is the 80/20 rule in IAM automation?
The 80/20 rule means fully automating the standard 80% of daily lifecycle events (standard joiners, lateral movers, terminations) while handling the complex 20% via semi-automated notifications that trigger manual intervention. This approach keeps initial delivery simple and on schedule.
What should an IAM project always start with?
Always start with a dedicated discovery/assessment phase before budgeting. Inventory systems and business processes, review HR data and Active Directory, and map the full user lifecycle. Only then can you produce a realistic implementation plan.
What makes a good IAM implementation partner?
A good IAM partner communicates openly, flags risks early, sets realistic priorities, and – critically – is willing to say ‘no’ to unnecessary customization. They act as long-term advisors, not just delivery contractors. The best indicator: do they push back when something will add maintenance burden without business value?