The Blind Spot in IAM: It Was Never Just an IT Project

The myth: IAM is about integrating applications

Integrating applications is the easy part. With fálaina5, connecting a typical application, one we already have a connector for, often takes less than a day. You point it at the system, map the attributes, test the connection, and the accounts start coming in.

What takes months is everything around it.

Who approves access to the finance system? When someone moves from Treasury to Operations, do they keep their old access for a handover period, and who decides how long? When HR enters a leaver on Friday afternoon, who removes access to the application nobody remembers owning? Which of the 300 groups in Active Directory actually mean something to the business?

None of these questions has a technical answer. Behind each one is a person, a team, a habit, and sometimes ten years of "this is how we've always done it".

IAM doesn't just integrate with applications. It integrates with people, and with the way a business really runs.

Integration goes both ways

I think of every IAM project as a two-sided integration.

On one side, the technology has to fit into the organisation: its structure, its culture and the way work really gets done. On the other side, the organisation has to change some of its processes to fit the technology, because automating a messy process just gives you a faster mess.

So the real question isn't "can the system do it?" It almost always can. The real questions are how far the technology should bend to fit the way we work, and how much change our processes, and our people, can take.

Get that balance wrong in either direction and you'll feel it. Bend the technology too far and you end up with a heavily customised system that's fragile and expensive to upgrade. Push the business too far and people find workarounds: shared accounts, access requested "just in case", approvals clicked through without being read.

Where projects get stuck

Here's a scene I've watched play out more than once.

The consultant presents the target design. "Best practice is that every access request is approved by the data owner, and every user's access is reviewed every quarter." Nobody argues with best practice.

Then the business speaks up. "Our branch staff cover each other's shifts at short notice. If a supervisor has to wait two days for the data owner to approve access, the branch can't open." Or: "We have 40 people doing the same job. Reviewing every one of them, line by line, every quarter, just isn't going to happen."

Both sides are right. The consultant is protecting the organisation from a real risk. The business is protecting its ability to operate. And because nobody has planned how to meet in the middle, the project stops moving. Workshops get rescheduled. The design document goes into its fifth revision. Go-live slips by a quarter, then another.

The technology was ready months ago. The people weren't ready to agree.

That's what I mean when I say IAM projects rarely fail because of the technology. They fail because of people. That isn't because people are difficult. It's because nobody planned for the people side of the change.

You don't have to take my word for it. Analysts and practitioners have been saying for years that a large share of identity governance deployments miss their scope, budget or timeline. The reasons they give are mostly about scope, unclear requirements and poor data, not about what the product can do.

How to be ready

If you're planning an IAM project, or trying to rescue one, here's my advice. Most of it happens before anything is installed.

1. Get your mindset ready first

Treat IAM as a business change programme that happens to involve technology, not a technology project that happens to affect the business. It changes how people join, move, leave, ask for access and prove compliance. That touches HR, line managers, application owners, risk, audit and every employee who has ever waited for a password reset.

2. Decide what you're willing to change, and what you aren't

Before the design workshops start, agree among yourselves which processes are open to change and which aren't. Every organisation has a limited appetite for change. Spend it where it removes the most risk, such as leavers, privileged access and access to sensitive data, rather than on reshaping things that already work.

3. Find a business sponsor, not just an IT owner

If everyone on the steering committee is from IT, decisions about approvals, roles and exceptions will stall, because IT can't make them alone. You need someone senior from the business who can say "yes, we'll change that" or "no, that stays".

4. Map how work really happens, not how the policy says it happens

Sit with HR while they process a new joiner. Ask a branch manager how they really get access for a new hire. Read the tickets. The gap between the documented process and the real one is where most of your design decisions are hiding.

5. Treat best practice as a starting point, not a verdict

For each "best practice", ask which risk it's meant to control. Once you know the risk, you can usually find a version the business can live with. Shift cover, for example, can be handled with pre-approved, time-limited access instead of a two-day approval chain. The control is still there. It just fits the way the branch works.

When something really can't fit, record it as an exception, with an owner and a date to revisit it, and move on. A documented exception is better than a stalled project.

6. Start small and prove it

Don't try to connect everything and redesign every process in phase one. Pick something that matters and that people will notice, such as making sure leavers in one business unit lose their access on their last day. Do it well, show the result, and let that success earn you the next phase.

7. Clean up your data and name the owners

Your IAM system is only as good as the data it's given. If HR records have the wrong managers, approvals go to the wrong people. If nobody owns an application, nobody can approve or review access to it.

And describe access in words the business understands. A manager can't make a sensible decision about "GRP_FIN_RW_02", but they can decide about "Can edit payment files in the Finance share".

8. Design for the people who'll use it every day

Most people will only ever see your IAM project in a few moments: asking for access, approving a request, reviewing their team's access once a quarter. If those moments are confusing or slow, people will rubber-stamp, work around the system or complain until it's switched off. Keep those moments simple.

9. Talk to people early, and keep talking

Explain why things are changing, what it means for each team and when it will happen. Train the approvers and reviewers, not just the administrators. And listen: the complaints in the first few weeks will tell you exactly where the design doesn't fit yet.

10. Measure what the business cares about, and keep going after go-live

"Number of applications connected" is an IT measure. The business cares about how soon a new joiner can work on day one, whether leavers lose access on the day they leave, how long access reviews take and how many audit findings come back. Report on those.

Remember, too, that IAM is a programme, not a project. Organisations restructure, merge, adopt new applications and retire old ones, and your IAM setup has to change with them. Make sure someone owns it after go-live.

The technology should be the easy part

I'll admit I'm biased: at fálaina, we build IAM technology. But that's exactly why I believe all this. The better the technology gets, the faster we can connect systems, and the clearer it becomes that the real work was always about people and processes.

That's how we've tried to build fálaina5: get the technology done quickly, so the time goes into the conversations that matter. Who should have access to what, who decides, and how the business wants to work.

If your IAM project is stuck in a design workshop, the answer probably isn't another product feature. It's getting the right people in the room and agreeing how far each side is willing to move.

If you'd like to talk it through, we'd be glad to help.

Request a demo →

Author: Chuah Kee Yin, CTO