In this article you will learn the 5 main reasons why identity management projects fail to succeed. These 5 reasons are based upon projects I have seen in the past 10 years. On some of them I have cooperated actively, on others I was close enough to be able to make an educated opinion.

But before I go into the details about why identity management projects not succeed entirely, I guess we should start off with a brief overview of what identity management (Idm) is all about and how most of the time it is implemented in organizations.

The user lifecycle

All identity management projects evolve around the fairly simple concept of the user lifecycle.

• When an employee is hired, she signs a contract. At this moment her relationship starts with the company and probably this information is entered in some IT system like Peoplesoft, SAP/HR or something else, maybe even a homebrewed system.  Depending on the function the employee will need to perform, access rights specific to her function are propagated towards other IT systems in a phase we know as provisioning.
• When the employee builds her career at the company, she might get a promotion or change jobs, change locations, or participate in different projects. All these events which occur in her career might also result in a change in access rights. This routine user management might trigger that additional rights are given (provisioned) or revoked (deprovisioned).
• Sometimes the user might need some support. She might have forgotten her password, or might just want to change some information about her. This is typically something where we do not want to call a helpdesk, but something which we can have her do herself through a self service application. Most self service applications offer at least some white page functionality, password reset or recovery capability, and some basic form of auto user maintenance.
• When this employee leaves the company all her accesses need to be revoked (for obvious security reasons) in a fairly automatic fashion. This is the deprovisioning phase.
• Off course, at some later stage the same person could work again for the same company, so when she is re-engaged, we come to a full circle.

Technical perspective

From a technical perspective most identity management systems work as set of event handlers/connectors and a message bus.

A typical setup for most identity management products on the market is an Idm-engine which talks to a message bus. This message bus is the communication channel on which standardized user lifecycle events circulate. These events are most of the time triggered by some step in the user lifecycle.

On this message bus are plugged a number of connectors which detect the event on the back end system and translate it in the standardized format known to the Idm-engine. The connector is most of the time specific for a type of back end system. So we could have for example an Oracle database connector, a SAP/HR connector, an LDAP connector, … The biggest names in Idm software have connectors for the most popular types of back end systems.

Besides connectivity, the connector offers a way to implement event monitoring (eg. Hire an employee) and data manipulation / scripting. The latter is needed to make information understandable by the message bus. In some cases it might need to undergo some transformation or validity checks. That’s why most Idm systems offer connectors where their behavior can be adapted/scripted for specific needs.

Identity Management seems simple: So why do projects still fail?

I’m sure you all agree that the concepts behind Identity Management are not too complex. It is clearly not rocket science. So if this is true, then why is it that projects still fail or not succeed in reaching the goals intended?

In the 10 years that I’m into this business I luckily have seen a lot of them succeed as well.

For those who didn’t work out well I’ve distilled the five main reasons why things went wrong. Off course, some projects succeed in combining some of these reasons. In those cases you don’t need a crystal ball to tell that things won’t work out fine at the end.

It is also true that there might be other reasons, which you might want to share in the comments below. My list is by no means exhaustive.

Reason 1 : Too much focus on technology

Some companies draft up an extensive RFP (Request for proposal), expect vendors to do some proof of concept (most of the time for free), they get a committee together to evaluate the technical proposals, decide, finally buy software from some lucky vendor, install it, and believe that their problems are solved.

This is a too simple view on things.

Sometimes too much focus is given towards technological aspects such as:

• How many types of connectors the Idm solution offers?
• Can it run on Linux, Solaris, Windows?
• What protocols are supported?
• Is the tool firewall-friendly?
• …

Don’t get me wrong, this stuff is clearly important in your choice when you need to decide about an identity management product.

But identity management is not about technology. Identity management uses technology to get things done. Therefore this technology is just a tool towards a goal: implementing the user lifecycle.

If things get too technical, then most of the time the projects are driven from an IT perspective. This IT perspective forgets sometimes that processes and collaboration between departments is crucial in succeeding the project. IT departments excel in technical stuff. They rarely excel in collaboration with business and in process (re)design.

Therefore, generally speaking, identity management projects should not be driven from inside the IT department.

Reason 2 : Processes not clear

I have seen in some organizations that there are a lot of different parties involved in the user life cycle. Therefore it is not always clear who needs to do what when a specific event occurs.

If these processes are not analyzed in a detailed way then nobody can configure the Idm system to automate the processes.

In these cases assumptions are made (most of the time to cover the company who actually does the implementation) about what the processes are believed to be.

This is not good, as the technically implemented reality might differ from real life.

My advice is not to make too many assumptions about the processes involved. Processes are extremely important in identity management. They are key in implementing a working automated user life cycle.

Idm people tend to forget: “The goal is to get things working. The goal is not to have you covered contractually when things go wrong.”

Reason 3 : Shit IN = shit OUT

I’m sorry about the heading, but I didn’t find one which was more appropriate!

I once got the input from a client: “all our phone numbers are stored in system XYZ”.

So linking up system XYZ with the identity management system would provide valid phone numbers for all users in the system.

Unfortunately, the client forgot to say (or didn’t know) that this was only true for people working in headquarters, not in the company centers around the country. So we could only trust this information for just a small part of the user population (about 10% of the population) and not for the entire population as we were told initially.

Another example was an HR system which was supposed to give valid user functions (which describe what kind of work the user actually does) upon which we could grant/revoke access rights in the user life cycle whenever a relevant event occurred.

After analyses it turned out to be that the functions mentioned in the HR system were some sort of gradation on a payment scale, and therefore were important for the payment of the employee, but had nothing to do with the actual work that the employee carried out. So this information was of no use whatsoever for provisioning the proper access rights.

What I’ve learned over the years is that if you take things for granted to quickly with data important to the user (and his derived access rights) that you are heading for disaster. You need to be able to trust the data in all connected systems. Otherwise you will have “bad” data circulating which might pollute all connected systems. So the saying: “Shit in = Shit out”, is especially true in identity management.

Reason 4 : Island politics – resistance to change

Administrators of servers and directories used to rule over their little islands with unlimited power. They basically could do (or not do) whatever they wanted.

Connecting a server or a directory to an identity management system will therefore intrude in their realm of power. The identity management system will know the accounts which have been created on the system.  Therefore, administrative actions which might have been done against security policies might become visible.

Also, the identity management system will create, modify and delete accounts on those connected target systems without the intervention of an administrator, just by the provisioning rules which are implemented in the Idm system.

There are administrators which see this as a way where management tries to limit their power and some of them even see mechanisms for reducing the number of administrators.

All this has a negative impact in their willingness when it comes to cooperation for the implementation of an identity management system. Sometimes administrators go even as far as not installing the necessary components to integrate their server or directory. I can assure you that they are creative when it comes to finding reasons for not installing. Anyway, it’s bad news for the project.

So how this should be handled then?

Well, in my experience it is best to involve the administrators of possible target systems from the beginning of the project and not put them before facts already decided for them. They should be made to see that identity management removes the hassle out of their daily jobs.

The daily work carried out by them can be more focused on real administration, such as improving performance, fault-tolerance, backup/restore, disaster recovery, network connectivity, and so on. I never met an administrator who told me that what he liked most in his work was creating, changing or deleting user accounts.

So identity management enables them to focus on the interesting stuff by leaving the routine work to some automated process. If this sounded a bit like politics, it was not intentional, but I suppose it is in some way.

Reason 5 : No or little support from senior management

Sometimes senior management just doesn’t care and sees identity management as some technical IT process (see also “too much focus on technology”).

I hope that I’ve demonstrated that processes and getting all the people involved with the project aligned in a proactive manner is extremely important.

The only people who can assure that everybody is aligned and committed to carry out their assigned tasks is senior management. It is their task to steer the different divisions/departments involved towards that common goal.

Ideally the identity management projects should be seen as a business enabler:

• Allow employees to be more productive in their jobs (get the right access rights faster)
• Removes strain on help desk (self service for routine user management tasks)
• Optimize general user management (have a grip on user accounts in the target systems, only needed accounts are provisioned)
• Compliance (knowing who got which rights when and why)

All of this is much broader than the IT department alone. I never have seen an identity management project succeed which didn’t have senior level support. It is that simple.

Conclusions

I agree with you that after reading this article you might think: “We shouldn’t start a project in identity management!”

That’s not a good idea either, especially because I would be without work fairly soon .

But knowing some of the pitfalls and trying to steer away from these common mistakes will enable your company not making these mistakes.

Sticking your head in the sand and closing your eyes never helped anybody to stay clear from trouble ahead.

So if you consider an identity management project prepare it well and take your time. Get your internal politics sorted out, get people involved proactively, explain the drivers for the project, and evangelize.

A wise man named Lao-tzu, a Chinese philosopher (604 BC – 531 BC), once said: “Even a journey of a 1000 miles starts with the first step.”

It is up to you to see that this first step is in the right direction …

Good luck !

Do you know other pitfalls? Do you agree or disagree with this article? The comments are open for your constructive insights. Feel free to share your toughts with the rest of the community!

Like the article? Share it with the social media buttons below. Thank you.