Your identity and access management project hasn’t failed. It has simply brought to light what no one previously wanted to voice or decide. We will tell it like it is: 80% of all identity management projects don’t fail because of the technology. They fail because of you, your organization, your unclear responsibilities, and decisions that no one has wanted to make for years. IAM is just the magnifying glass.
We’ve been helping companies implement centralized authorization systems for years. And the pattern is always the same: The project starts with architecture workshops, tool evaluations, and connector concepts. Everyone is motivated. Then comes Phase 2, the role design, and suddenly everything goes quiet.
Why? Because role design means defining who is allowed to do what. And by doing that, we also define who is no longer allowed to do certain things. This is not an IT issue – it is a power issue, in some organizations even a battle between Silo A and Silo B.
Here are five truths from our practical experience.
The tool is irrelevant
SailPoint, Tenfold, Omada – all solid products. But none of them will solve your problem if you do not know who in your organization is authorized to decide which access rights a claims processing employee actually needs. You are buying a key management system, not a floor plan. The IAM tool manages the keys – but only your role model defines which person is allowed to open which door.
Recertification is often just a show
Every quarter, managers click “Approve” on lists of access rights they do not understand, for employees whose current responsibilities they do not know, in systems they are hearing about for the first time. That is not control – it is compliance theater. And every auditor who accepts this process becomes part of the problem.
Your “historically grown” access rights are not a legacy – they are technical debt
Every employee who changed departments but kept their old permissions represents an open vulnerability. Not someday – right now. The cumulative risk created by ten years of “let’s leave the access for now, they might still need it” is so significant in many organizations that an honest access audit should make executive boards nervous.
And rightly so: according to BaFin, even in financial institutions – where strict regulatory requirements have existed for years, not only since DORA – access management is inadequately implemented with significant or severe deficiencies in every second institution.
IAM projects are organizational transformation initiatives that are too often treated as IT projects
No CIO will tell the board: “We are launching a project to clarify responsibilities, power structures, and decision-making bottlenecks.” But that is exactly what happens when a centralized access management system is introduced. The project proposal may be called “IAM implementation,” but the reality is: “We are forcing every department to document its responsibilities in black and white.” Anyone who fails to understand this plans for a twelve-month project – and then wonders, 24 months later, why they are still stuck in phase two.
The most expensive sentence in an IAM project: “We’ll clarify that later.”
Every decision postponed during role design does not just block one application – it blocks every application built on top of that role model. In an environment with 200 connected applications, a single delayed design decision can cost weeks. Not because the technology is waiting, but because nobody can move forward until it is clear, for example, whether a claims team leader is allowed to approve payments.
What works instead?
Three things that cost no budget but almost never happen:
Before the first architecture workshop, set up a decision matrix that defines who resolves role conflicts definitively. Use names, not organizational chart boxes. If you write “the business department decides,” you’ve already lost – because “the business department” does not have an email address.
Every application that is to be integrated must name an Application Owner who is mandated to revoke access rights. Not to grant them. Anyone can grant access. Revoking creates conflict – and that is exactly why a mandate is needed.
Stop structuring IAM as an IT project. The project team needs more organizational developers than software engineers building connectors. If you reverse this ratio, you will build fast interfaces to systems where nobody actually knows what permissions should be assigned.
We see this again and again: technology is ready after three months. The organization needs 24 months – or blocks itself completely. If you ignore this imbalance in planning, you create a project that is officially “in implementation” but in reality fails due to missing decisions.
IAM is the moment when an organization must be honest with itself. Those who understand this can successfully implement any tool. Those who don’t will fail with every tool.
For more information, play the video below:
