How IAM Projects Fail: Three Traps, Part I

IAM (Identity and Access Management) projects have a history of unfortunate disasters to the tune of millions and tens of millions of dollars. How can you ensure your IAM projects become milestones of success for your organization instead of expensive lessons in how not to fail?

In this series of blog posts, we will discuss three traps to avoid based on our IAM experiences and industry recommendations.

Trap #1: Boiling the Ocean

The “boiling the ocean” trap could apply to any enterprise initiative, but is especially true for IAM projects. Because IAM, eventually, touches a huge number of organizational processes (provisioning, access control, certification, etc.), there is a tendency to attempt to do everything at once, a task comparable to trying to boil the ocean. The IAM vendors will prod this approach along by encouraging your company to buy a full suite solution up-front instead of just the pieces you need at the moment.

The problem with this approach, or boiling the ocean for that matter, is that while it is theoretically possible, any attempt of this scale is likely to fail. Within each area of IAM, there are simply too many moving pieces. Within any given organization, there are usually also too many departments and too many applications. To IAM-enable every department and application for all aspects of IAM in one effort involves thousands of individual tasks and could involve years of man-hours.

Additionally, these “boil the ocean” attempts are often accompanied by a grand strategic plan, promises of Nirvana to management, and massive multi-year budgets. As software development organizations have learned, when dealing with complex technology and shifting requirements, attempting to plan, specify, and quote (let alone execute) massive projects up front is a recipe for disaster. There is simply not enough accurate information available to make on-target assumptions.

The result of the “boil the ocean” approach can be seen in the wreckage left from the IAM attempts in the early 2000’s: massive budget overages, management disillusionment, lack of internal support, and half-working IAM systems.

Don’t make this typical but easy-to-avoid mistake: instead, start small and focus on quick wins. That’s not to say that you shouldn’t start with the end in mind and look at the bigger picture, but it is to say you shouldn’t make detailed plans at that scale. In a subsequent posting, we’ll talk about IAM success factors and how to ensure rapid, prioritized IAM deployments.

In our next post in this series, we’ll focus on the second major trap, one that results in organizational friction, annoyed users, and processes that don’t seem to make sense.