Why IAM programs fail when teams start with the project plan

At a glance

What this is: This is a practitioner argument that IAM and IGA programmes fail when teams begin with project mechanics instead of business-defined identity problems.

Why it matters: It matters because IAM leads, architects, and governance teams need a business-first operating model that covers human, NHI, and lifecycle controls rather than treating identity as a routine IT rollout.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Fischer Identity's analysis of why IAM programmes fail when teams start with the project plan

Context

Identity and access management is not just a tooling exercise. In complex organisations, the programme defines who can reach systems, data, and workflows, which means the real problem is often not technical deployment but deciding which identity pain points matter most and how they affect the business.

That is why project-first IAM efforts struggle. When teams begin with a timeline, a vendor shortlist, or a go-live date, they skip the discovery work that exposes lifecycle failures, excessive access, audit exposure, and manual workarounds. In higher education, healthcare, and non-profit environments, that gap is usually the difference between a sustainable programme and a stalled one.

For teams trying to build the right foundation, the useful starting point is the programme problem set, not the implementation plan. The best-known NHI lifecycle patterns in our Ultimate Guide to NHIs show why scope, visibility, and offboarding have to be understood before the work can be sequenced.

Key questions

Q: How should organisations start an IAM programme without making it a pure IT project?

A: Start with business pain, identity lifecycle failures, and audit risk, then translate those findings into scope and requirements. A project plan should follow discovery, not replace it. That sequence keeps the programme aligned to mission needs and prevents the team from building around assumptions that have never been tested.

Q: Why do IAM programmes often fail when scope is defined too early?

A: Because early scope usually reflects guesses about identity populations, integrations, and lifecycle complexity. Once those assumptions are written into the plan, the programme inherits rework, delays, and governance gaps. Discovery first, scope second is the more reliable sequence for both human and non-human identity programmes.

Q: What breaks when teams estimate IAM effort before mapping identity complexity?

A: They underestimate the number of integrations, exceptions, and identity types that drive the work. That usually leads to unrealistic dates, underfunded testing, and weak lifecycle design. In practice, the programme becomes harder to govern because the plan was built without a real model of the environment.

Q: Who should be accountable for defining IAM requirements in a new programme?

A: Accountability should sit with identity, security, and the business owners who depend on access outcomes, not with the PMO alone. The programme is governing access to services and data, so the people affected by those access decisions must help define the requirements and risk priorities.

Technical breakdown

Why identity programmes fail when scope is defined too early

IAM programmes often fail because scope is treated as a scheduling exercise rather than an identity model. If the team has not mapped user populations, source systems, lifecycle states, and governance pain points, the resulting plan will encode guesses as requirements. That creates rework in provisioning, access reviews, certification, and offboarding. The technical issue is not project management itself, but premature commitment to assumptions that have not been validated through discovery.

Practical implication: do discovery across identity populations and lifecycle gaps before a timeline is approved.

How business pain points become IAM requirements

A workable IAM requirements catalogue starts with operational friction: duplicate identities, orphaned accounts, excessive access, manual approvals, and delayed deprovisioning. Those findings must be scored by business risk, compliance exposure, and operational impact. In practice, this turns anecdotal complaints into a prioritised backlog that can justify controls such as access reviews, delegated administration, federation, or automated lifecycle orchestration. Without that step, implementation effort is usually spent on low-value convenience work instead of risk reduction.

Practical implication: convert stakeholder pain into a scored requirements list before selecting delivery milestones.

What level-of-effort estimation really depends on

Effort estimation in IAM is driven by identity complexity, not just headcount. The real variables are the number of identity types, the quality of source data, the number of downstream applications, and whether the programme must handle non-employee identities, delegated access, or MFA enrolment. These dependencies matter because IAM work is mostly integration and exception handling. If they are not counted up front, the project plan will underestimate testing, mapping, and governance overhead.

Practical implication: estimate integrations, identity types, and exception handling before committing delivery dates.

NHI Mgmt Group analysis

IAM programme failure is usually a discovery failure, not a delivery failure. Teams often blame implementation discipline when the deeper issue is that they never defined the identity problem set in business terms. If lifecycle breaks, orphaned access, and manual workarounds are not captured early, the programme is forced to optimise around incomplete requirements. The implication is that IAM governance must begin with problem definition, not execution planning.

Identity scope is a governance boundary, not a project artefact. Once organisations choose the wrong starting assumptions, they lock in constraints that affect every later decision, from integration design to certification cadence. That is why a project plan cannot substitute for business alignment. Practitioners should treat scope as a control decision that determines who and what the IAM programme is actually governing.

Non-employee identities make the business-first model even more important. The moment a programme has to manage adjunct faculty, visiting nurses, volunteers, or other non-standard identities, the complexity stops looking like a standard IT rollout. NHI scale and lifecycle variance change the operating model materially. In other words, the identity team is not just installing software, it is defining the rules of access for multiple classes of actors.

Attribute-level understanding and lifecycle visibility are the real prerequisites for credible IAM design. A programme cannot govern what it cannot distinguish, and it cannot prioritise what it cannot measure. The same logic applies across human identity, NHI, and delegated access: the programme must know who or what exists, which relationships justify access, and where the lifecycle breaks down. That is the basis for durable IAM architecture, not the project calendar.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a wider lifecycle lens, read Ultimate Guide to NHIs for the governance patterns that make access scope, visibility, and offboarding measurable.

What this signals

Identity programme planning should now assume that non-human populations will dominate the governance workload. With NHIs outnumbering human identities by 25x to 50x in modern enterprises, the traditional project mindset is too small for the problem. Teams that still treat IAM as a single-workstream rollout will miss the real operating model shift, especially where lifecycle and offboarding are involved.

Scope discipline will increasingly determine whether IAM becomes a governance function or just another implementation queue. The organisations that succeed will be the ones that define identity populations, lifecycle states, and business-critical pain points before they select delivery milestones. That is the difference between a programme that scales and one that merely deploys software.

For practitioners

• Run identity discovery before project planning Gather input from helpdesk, HR, compliance, IT, and business owners to document the real access problems, not just the requested features. Use those findings to define scope, risk, and the sequence of work before any timeline is approved.
• Build a scored IAM requirements catalogue Rank lifecycle failures, excessive access, duplicate identities, and manual workarounds by business impact and urgency. Use that catalogue to justify design choices and to prevent low-value implementation work from displacing the controls that matter most.
• Estimate effort from identity complexity, not optimism Count identity types, downstream applications, exception paths, non-employee populations, and integration dependencies before committing delivery dates. This produces a realistic plan and exposes where automation, governance, or cleanup work will dominate the schedule.
• Treat lifecycle failures as programme inputs Document onboarding, offboarding, provisioning, and access review breakdowns as design requirements, not operational noise. If a process is failing repeatedly, the IAM programme should absorb that failure pattern into the architecture rather than planning around it.

Key takeaways

• IAM programmes fail when they begin with the project plan instead of the identity problem set.
• Discovery, lifecycle analysis, and business risk scoring are the real prerequisites for realistic scope and effort estimates.
• Non-employee identity scale makes business-first IAM design more urgent, not less.

Key terms

• IAM Programme: An IAM programme is the organised set of governance, process, and technology work needed to control who can access what and under which conditions. In practice, it spans lifecycle, access policy, assurance, and reporting, and it must be aligned to business risk rather than treated as a simple system implementation.
• Identity Discovery: Identity discovery is the process of finding and cataloguing every identity, entitlement, and access path across the environment. In NHI programmes it is foundational because hidden service accounts, tokens, and machine identities create governance gaps that certification and offboarding cannot close.
• Lifecycle Failure: Lifecycle failure is any breakdown in onboarding, provisioning, review, or offboarding that leaves access incorrectly assigned or retained. It is one of the clearest indicators that IAM design is out of sync with how the organisation actually operates, and it should shape programme requirements early.

What's in the full article

Fischer Identity's full blog covers the operational detail this post intentionally leaves for the source:

• The full discovery checklist for mapping IAM pain points across helpdesk, HR, compliance, and business leadership.
• The step-by-step scoping logic for estimating effort across identity types, applications, and exception paths.
• The vendor's examples of lifecycle failures, technical debt, and integration gaps that should feed a requirements catalogue.
• The broader advisory framing for turning business pain into a programme plan and delivery sequence.

👉 The full Fischer Identity post expands the discovery questions, scoping sequence, and business-aligned planning approach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.