Why are Organizations Struggling with IAM Projects?

Originally published by Avanade.

Written by Martijn Zantinge.

According to research, the number of identity & access management (IAM) projects that don't achieve their initial goals is alarmingly high. I know very few other solution areas within IT that have such a poor track record when it comes to achieving goals. Having worked in the IAM solution domain for the last 15 years, you start to see patterns in the cause of this extremely high percentage of failing projects.

While in the early years, many of the challenges were caused by immature software solutions. Those days are largely behind us. Let me be clear, I am not saying that immature IAM software does not exist. IAM, like many other areas of security, is constantly evolving. Think of all the exciting new developments that have taken place in recent years, such as Verifiable Identities and Multi-Cloud Access Management. Part of the novelty of these developments is that the software is not yet ready. However, few companies have reached the maturity to start implementing these new solutions, and from experience, the vast majority of projects that run into problems are not caused by immature software solutions.

There are various lists available on this topic, including causes such as unsupported processes or lack of stakeholder support. These are all valid reasons that cause problems, but in my experience, they do not seem to be the main cause of the poor track record.

In fact, in many projects, I have come across three main pitfalls, all of which I would like to highlight below so that these pitfalls can be recognized in time to avoid them.

I want it all, and I want it now

The purchase of IAM solutions is seen as a major investment for organizations, and therefore an optimal return on investment (ROI) is expected. This means that many organizations expect to fully utilize the functionalities of the solution.

While this makes sense from an ROI perspective, organizations often underestimate the complexity of IAM. No matter how mature an organization is in terms of security, IAM projects are and will remain complex. There are a large number of stakeholders to consider, processes to align, and an enormous number of variables to take into account. Organizations often underestimate this complexity. Trying to implement it all at once is like trying to drive a Formula 1 car for the first time; at best it's guaranteed to send your anxiety levels through the roof, but more likely you'll crash, resulting in huge collateral damage.

No roadmap

While this is obviously a metaphor, it is applicable to IAM implementations. It's good to define that 'North Star' on the horizon. But rather than approaching it as a big project, the organization should not view an IAM implementation as an end goal. It is a continuous journey with many small stops along the way. Between those stops, it's important to align with the business to understand its needs and determine the path forward. This brings us directly to the second pitfall.

Organizations often don't have an IAM strategy in place or they don't have a roadmap that aligns with that strategy. As a result, you often see IT departments simply implementing IAM solutions without a perspective and alignment on how IAM will support the business. I've been in numerous discussions where IT has determined the path forward without alignment with the organization. This is resulting in conversations where stakeholders do not understand each other, processes that don't align with the technical implementation, poor integration, and overall frustration.

Copy/paste and run

However, one of the biggest flaws I see, though less common, will almost guarantee disappointing results. This is the requirement to migrate “as is”. This is definitely not just an IAM issue, but more of a general implementation misalignment.

Many organizations have an existing IAM solutions in place. The processes and functionalities are defined within the tooling, but for various reasons, such as the End of Life (EOL) of the current IAM solution, or a move to a cloud-native strategy, the existing solution can no longer be supported. Much of the functionalities of IAM solutions is identical, any mature IAM solution can support the Joiner, Mover, and Leaver processes and various variations of these. Of course, there are obvious differences in the look and feel, and in how to configure the functionalities.

Where the problems arise is in the order of these processes, knowledge and workflows can vary between solutions. More importantly, IAM solutions have often been running within the organization for years, with varying degrees of customization. Especially with the move to the cloud, standardization and parameterization have become the norm, limiting the ability to customize. With the arrival of SAAS solutions it generally has made it easier to upgrade and the chances of bugs being introduced are significantly reduced. However, it does mean that you have to stay within the boundaries of the standard capabilities of the software and, as with anything new you buy, you cannot expect it to work the same or support the same functionality. Instead, organizations should see this as an opportunity to optimize and standardize processes. Today, all mature products are based on best-practice workflows and support numerous processes and use-cases to ensure optimal functionality. Organizations should invest time in trying to adhere to these standards as much as possible, rather than trying to support the exceptions.