Why Your IGA Project Failed — And How to Recover Without Starting Over 2026

Industry surveys consistently report that 60-70% of enterprise IGA (Identity Governance and Administration) deployments fail to deliver against their original business case within the planned timeline. The number has been roughly stable across analyst frameworks (Gartner, Forrester, KuppingerCole) for the better part of a decade. The pattern is so common that it has its own operational signature: the platform is in production, the system integrator left, the help desk still fields most routine access requests, certification campaigns happen on paper but produce nothing actionable, and leadership wants to know why the multi-million-dollar identity program isn't delivering against the business case it was originally funded against.

If your IGA program is in this state, the good news is that the failure pattern is well-understood and the recovery path is too. Most stalled IGA programs don't need to be restarted from scratch; they need to be re-baselined and narrowed. The platform is usually appropriate; the implementation overreached. The 2026 enterprise reference path is phased recovery — four operations across 9-18 months — that delivers outcomes substantially faster than a full restart and is substantially more likely to succeed.

This piece is the 2026 strategic reference on stalled IGA recovery. The four failure patterns that produce the stall, the restart-vs-continue decision framework, what the phased recovery actually looks like operationally, and how the recovery fits into the broader maturity model. The companion pieces cover adjacent layers: the Identity Maturity Model piece covers the broader maturity ladder (most stalled IGA programs are at Stage 2, recovering toward Stage 3), the Best IGA Solutions buyer guide covers the platform landscape if restart turns out to be the right call, and the HRIS-Driven Lifecycle piece covers the foundational data discipline that recovery depends on.

Four zones, one operational arc. The recovery path doesn't require throwing out the platform — it requires narrowing the scope, refreshing the baseline, and restarting against operational reality.

Why IGA projects fail so often

The 60-70% failure rate is structural, not coincidental. Three patterns produce the stall across most failed deployments.

Scope ambition exceeds maturity. IGA projects are typically scoped against an aspirational future state. The business case promises Stage 3 or Stage 4 maturity (per our Identity Maturity Model framing): joiner-mover-leaver automation, full certification coverage, audit position improvement, help-desk volume reduction. The starting point is usually Stage 1 (Manual/Reactive) or early Stage 2 (Tooled but Inconsistent). The maturity jump implied by the scope is two stages in a single project — and the project plan accounts for the work to deploy the platform but rarely accounts for the operational discipline required to advance two maturity stages simultaneously. The project completes the platform deployment on schedule and never reaches the planned operational outcomes.

Connector landscape exceeds the initial scope. The project plan identifies the major target systems for integration — Active Directory, Microsoft 365, the ERP, the primary CRM, a few HR systems. The deployment integrates those systems on schedule. Then the project discovers that the actual workforce uses dozens of additional applications that need integration too — Salesforce custom orgs, Workday or SuccessFactors HR modules, AWS accounts, Azure subscriptions, the Snowflake data warehouse, half a dozen niche SaaS applications acquired through team-level procurement. The connector backlog grows faster than the integration team can clear it. Certification campaigns review a small subset of the actual entitlement surface. The shadow-provisioning pattern documented in our Shadow IT Provisioning piece fills in the gap that IGA didn't cover.

Operational discipline is under-funded. IGA programs require schema mapping, certification cadence, workflow design, change management, target-system reconciliation, stakeholder education, ongoing platform tuning. The project budget typically funds the platform deployment and the initial connector integration. The ongoing operational discipline is assumed to be either covered by the platform itself (it isn't) or absorbed by the existing IAM team (which doesn't have capacity). The result is deployments where the platform is technically operating but the operational outcomes that the business case promised aren't materializing.

The three patterns compound. The scope ambition produces a project that needs operational discipline to succeed. The connector backlog reveals that the scope was structurally larger than planned. The under-funded operational discipline means the program can't recover the schedule or the outcomes. The deployment ends up in a state that looks like progress on paper (platform deployed, some workflows running, occasional certifications completed) and doesn't deliver against the business case (help desk volume unchanged, audit position unchanged, IAM team still firefighting).

The four failure patterns in stalled deployments

If your IGA program is showing the failure signature, the specific patterns producing the stall are usually some combination of these four. Most stalled deployments exhibit two or three; the worst-stalled exhibit all four.

Connector backlog. The IGA platform integrates with a subset of target systems but most of the workforce's actual access surface isn't covered. The certification campaigns review a small fraction of total entitlements. The lifecycle automation only covers the integrated systems. Manual provisioning persists for everything else. The metric is the percentage of total enterprise entitlements that the IGA platform is aware of — in stalled deployments this is often 30-50%, sometimes lower. In Stage 3 mature deployments, the number is 85-95%.

Workflow complexity. The access-request forms are 47 fields long. The approval routing is unclear. The self-service portal is unfamiliar. The user experience is so poor that requests flow through informal channels (Slack DMs, ServiceNow tickets routed to direct grants, direct admin requests) instead of through IGA. The platform records few requests because few users complete them. The metric is the ratio of IGA-mediated access requests to total access provisioning events — in stalled deployments this is often under 20%, with the rest happening through shadow paths.

Catalog drift. The IGA catalog diverged from the actual entitlement state in target systems. Shadow provisioning has been happening for years; reconciliation isn't running; the catalog reflects what IGA was told about, not what the target systems actually have. The IGA-visible reality is fundamentally different from operational reality. Audits that probe this gap (the 2026 sophisticated audit profile documented in our Access Review piece) produce findings. The metric is reconciliation rate — the percentage of target-system entitlements that match IGA-known entitlements. Stalled deployments rarely measure this because the answer would be uncomfortable.

Stakeholder fatigue. Managers stopped engaging with certification campaigns because the campaigns produced too much noise and not enough actionable signal. Attestations became pattern-clicks. The audit position weakened. The CISO stopped attending IGA program reviews because the same status report kept coming back unchanged. Leadership funding for IGA program expansion went cold. The metric is engagement quality — the percentage of attestations that show evidence of substantive review — and in stalled deployments this is often near zero.

The four patterns are operationally addressable, but the addressing requires explicit scope narrowing and re-baselining, not just additional integration work.

The restart vs continue decision

Before launching into recovery, the strategic question is whether the platform itself is appropriate. If it isn't, recovery will deliver outcomes shaped wrong for the environment and the program will need to be restarted eventually anyway. If it is appropriate, recovery is faster and more likely to succeed than restart.

Restart in these scenarios:

The platform is fundamentally wrong for the environment. Enterprise IGA platforms (SailPoint, Saviynt, Omada, Microsoft Entra ID Governance, Avatier Identity Anywhere) are designed for complexity that mid-market organizations don't have; lightweight IGA platforms are designed for simplicity that enterprise organizations don't have. If the platform mismatch is structural, recovery papers over the mismatch and never resolves it.

The original scope was so divergent from operational reality that recovery would require more work than starting fresh. This is rare but real. If the connector landscape required is 10x what was originally scoped, if the workforce is dramatically different in composition from what the project assumed, if the underlying HRIS or directory has been completely replaced, the recovery may not have a sensible starting point.

The platform vendor went out of business or is exiting the market. Less common in 2026 (the major vendors are stable) but it does happen.

Continue with recovery in every other scenario. The pragmatic test: if you took the same project team that built the current stalled deployment and gave them a fresh start, would they make substantially different platform decisions, or substantially different operational decisions? If the answer is "substantially different operational decisions," the recovery path is right. If the answer is "substantially different platform decisions," restart makes sense.

In our experience working with stalled IGA programs, the recovery answer is correct in 75-85% of cases. The platform is usually fine; the implementation was too ambitious.

The four-phase recovery path

Recovery operates in four phases, typically 60-90 days each, for a total timeline of 9-18 months. Each phase has specific operational outputs and a clear go/no-go decision before the next phase begins.

Phase 1 — Audit what's actually working (60-90 days). Inventory the operational state honestly. Which connectors are integrated and producing useful data? Which workflows are actually being used (not just configured — actually used by people)? Which certification campaigns produce actionable findings (entitlements removed, conflicts resolved, ownership transferred — not just attestation events)? Which target-system reconciliations are running and producing meaningful drift signal? Which segregation-of-duty rules have fired and produced action versus fired without consequence? Which HRIS-driven lifecycle workflows are actually running automatically versus requiring manual intervention?

The audit produces a list of what's working — usually larger than the team initially realizes — and what's not. The audit's strategic value is shifting the program from "everything is broken, we need to fix it all" to "these specific things work, these specific things don't, here's the operational baseline to build from." That shift is psychologically as important as the operational findings.

Output: an operational baseline document and a prioritized list of failure patterns to address.

Phase 2 — Stop trying to cover everything (60-90 days). Pick the workforce segment with the highest leverage and explicitly defer the rest. The leverage criterion: broadest user population at the easiest-to-integrate target systems with the strongest existing operational baseline. For most enterprises, this is the corporate workforce (HQ + major offices, excluding contractors and frontline) operating against the major identity systems (AD, M365, Salesforce, the primary HR system). The deferred segments — contractors, frontline workforces, niche target systems, mainframe environments, specialized applications — get explicit deferral with documented future-phase plans.

The scope reduction is the recovery's most important move and the hardest one for project leadership to accept. The original business case promised comprehensive coverage; the recovery path requires explicit narrowing. The narrowing produces operational outcomes; comprehensive coverage produced none.

Output: a narrowed-scope program charter with explicit deferred segments and timelines for future expansion.

Phase 3 — Re-baseline against current organizational reality (60-90 days). The HRIS attribute mapping that was designed two years ago doesn't match the current organizational structure. The role definitions drifted as the business reorganized. The segregation-of-duty rules need adjustment for the actual workflow reality. The certification cadence and reviewer assignments need reconsideration. The integration with the IGA platform needs schema refresh.

This phase is operationally unglamorous but foundational. The CGov HRIS-Driven Lifecycle piece covers the schema-mapping discipline that this phase depends on. Without re-baselining, the narrowed scope produces results that look fine on paper and don't match operational reality.

Output: refreshed schema mapping, role definitions, SoD rules, and certification configuration aligned to current organizational state.

Phase 4 — Restart with narrowed scope (60-90 days). Run the IGA platform against the narrow scope with the refreshed baseline. Measure outcomes against the original business case: help desk volume reduction, audit position improvement, certification engagement quality, lifecycle automation rate, catalog accuracy. The metrics should improve substantially in the narrow scope because the platform is now appropriate for what it's being asked to do.

Once outcomes are positive in the narrow scope, the expansion plan can resume — bringing the deferred segments back in one at a time with operational discipline. The expansion is the Stage 3 to Stage 4 transition covered in the Identity Maturity Model piece; the recovery itself is the Stage 2 to Stage 3 transition.

Output: measurable program outcomes and an expansion roadmap.

Four phases, gated by outcomes. The recovery isn't a single 18-month project; it's four sequential 60-90 day phases that can be paused, recalibrated, or terminated if outcomes aren't proving.

What recovery looks like operationally

Three months in, the operational signature of a working recovery looks different from a stalled deployment in observable ways.

Help desk volume on routine access for the narrowed scope drops substantially — typically 50-80% reduction in the first measurement window. The narrowed scope means fewer requests overall, but the per-request automation rate climbs because the workflows actually work for that segment.

Certification campaign engagement quality improves measurably. Reviewers see the focused scope, find decisions they can actually make, and the attestation evidence shows substantive engagement. Audit walkthroughs of specific decisions can answer the auditor questions documented in our Access Review piece.

Catalog reconciliation runs continuously and produces a measurable accuracy rate — typically 90%+ in the narrowed scope once the re-baseline completes. The shadow-provisioning gap (the Shadow IT Provisioning piece) is bounded and tracked.

Lifecycle automation covers the joiner-mover-leaver workflow end-to-end for the narrowed segment. New hires are provisioned before start date; leavers are deprovisioned same-day; movers get clean entitlement diffs.

The IAM team's time shifts from firefighting to operational improvement. The capacity recovery — 30-50% of the team's time becoming available for architectural work rather than ticket triage — is what enables Phase 4's expansion planning.

Where recovery breaks

Three failure modes recur in recoveries that don't deliver outcomes despite executing the four phases.

Scope creep during recovery. Leadership pushes for "while you're at it, can you also cover the frontline workforce / the mainframe / the contractor population / the recently acquired subsidiary." Each addition extends the timeline and dilutes the focus. The mitigation is explicit charter discipline — the deferred segments stay deferred until Phase 4 produces measurable outcomes against the narrowed scope.

Phase-gating not enforced. Phases get blended ("we're working on Phase 1 and Phase 2 in parallel"), or Phase 1 audit findings get ignored ("the audit said these workflows weren't working but we kept them anyway"). The phasing discipline produces the operational learning; skipping the phases produces deployments that look advanced and aren't.

Leadership patience runs out. Recovery is a 9-18 month timeline. Leadership that expected immediate turnaround sometimes withdraws funding partway through. The mitigation is explicit milestone communication — Phase 1 produces the operational baseline, Phase 2 produces the narrowed charter, Phase 3 produces the refreshed foundation, Phase 4 produces measurable outcomes. Each milestone is reportable and demonstrates progress.

The mitigations layer. Charter discipline plus phase enforcement plus milestone communication produces recoveries that deliver. Skipping any of them produces recoveries that look like the original deployment in disguise.

The 2026 reference path

Acknowledge the failure pattern. Industry-wide 60-70% failure rates mean that if your IGA program is stalled, the pattern is normal — not evidence of organizational dysfunction. The recovery path is well-understood; executing it is the work.

Make the restart-vs-continue decision explicitly. The platform is usually appropriate; the implementation overreached. Recovery is the right answer in 75-85% of cases.

Execute the four-phase recovery with discipline. Audit what's working, narrow the scope, re-baseline against current reality, restart in the narrow scope. Each phase 60-90 days. Each phase gated by outcomes.

Frame the recovery as Stage 2 → Stage 3 maturity advancement, not "fix the failed project." Leadership understands progressive maturity better than they understand project rescue. The Identity Maturity Model piece covers the framing that pairs well with recovery work.

Compose with the broader stack. The Best IGA Solutions buyer guide covers the platform landscape if restart is the right call. The HRIS-Driven Lifecycle piece covers the foundational data discipline that Phase 3 depends on. The Shadow IT Provisioning piece covers the catalog accuracy work that Phase 1's audit will surface. The AI Access Certification piece covers the certification engagement improvements that Phase 4 can deploy.

IGA project failure is common. Recovery is straightforward when the discipline is applied. The platforms that successful recoveries run on top of are usually the same platforms the stalled deployments were running on top of all along. The difference is operational, not technological. Make the operational discipline the focus of the recovery, and the program that was supposed to deliver Stage 3 maturity in 18 months and didn't will deliver it in another 12-18 months — substantially faster than the alternative of starting over.