Top 10 Common Pitfalls of an IAM Initiative

  

 Email Article  

Tweet  

  

Hard to believe, but I've been in Identity and Access Management for 14 years. Time flies when you're having fun.

Over this time I've grown and my hair has gone gray a bit. I've been reflecting on my journey so far:  If I had a chance to go back to a particular point in time, I often ask myself, what would I have done differently?

The answer? A few things-personal and professional. For one thing, pursuing a career in professional soccer would have been nice (the thought tends to come back every 4 years in time for the FIFA World Cup). Professionally, I would have taken a slightly different approach to IAM projects and initiatives. In pondering this existential question, my colleagues and I have assembled a very valuable asset-a list of top 10 common pitfalls of an IAM initiative. We use it consistently in our advisory services area to help customers define their IAM roadmap and implementation plan as part of our very popular Kickstart Program.

This list helps us achieve some consistency and a pragmatic flavor in our recommendations; we would not recommend something that runs counter to our experience. We include it in our deliverables and always illustrate each pitfall with a few personal stories, which resonates well with our clients.  It sparks discussion.

In a recent session with a client, a senior stakeholder said: "you know, this list could be applied to any IT initiative, not just to IAM". This to me was somewhat of a revelation, and might give the list below a much broader use, even though it originated from our focus only in identity.

So, with that preamble, and in no particular order, I give you our list of the "Top 10 Common Pitfalls of an IAM Initiative":

1. Focusing on technology before business processes - IAM is far more than technology. Many would argue that it is more aligned with business processes than technology. Yet, many times an IAM initiative is so heavily focused on products and automation, that very little focus is given to business processes. In our experience this results in user dissatisfaction and inefficiencies, where tasks are done in a certain way because "that's how the tool does it." In the long term, this often results in the project being deemed a failure, and the only option being a rip and replace (regardless of the product or technology choice).
2. Automating bad processes - Somewhat related to the prior, but slightly different. Defining a business process is one thing; having a good business process is another. We have seen many examples of this, but one I recall was a scenario in which the on-boarding process took too long and impacted business; so in order to expedite it, a provisioning process was defined and automated, triggered from the entry being added in HR. However, the process of creating the individual's record in HR was done manually after an ad hoc workflow between the HR recruiting to payroll groups completed. And in this handshake there were two points of manual data entry for the same information, and an informal notification process. Downstream, this led to very expedient creation of duplicate accounts for the same user, and at best a marginal shortening of the on-boarding time, often overshadowed by a very convoluted clean-up process.
3. Having an unsupportable infrastructure (leads to abandoning the roadmap) - This one reminds me of Pierre (from Chapter 7 of Tom Freese's "It only takes 1%"). You can have the best IAM solution possible today, but if it takes too much effort to maintain, or if it is so customized that it cannot be effectively supported over time, then it ultimately ends up being abandoned. Assuming that your IAM solution leverages vendor-supplied technology, here is where the Pareto principle is best applied: 80% of the functionality in the infrastructure should be standard functionality of the product, 20% should be customized functionality. Beyond this balance, the infrastructure quickly becomes unsupportable (just wait for the first upgrade cycle).
4. Lack of a roadmap (the initiative loses direction) - There could have been a tactical need that triggered the initiative, or perhaps it was originally driven by a department or line of business. However, without a defined evolutionary path, aligned with business objectives, it is all too common to see the initiative dissipate and implode. Here is when we see customers implementing similar solutions in different parts of the organization, rather than leveraging one, as well as ripping and replacing existing IAM infrastructure; devolving into a vicious cycle, ala Bill Murray's Groundhog Day. Becoming reactionary in nature, reacting to immediate needs, such as technology upgrades or incremental functionality needs, sans roadmap. The symptom we tend to find during our assessments is that the organization is constantly reacting to IAM requirements, as opposed to anticipating them.
5. Lack of executive sponsorship - I concede that this one is far from unique to IAM, as it would be common to any IT initiative. But this is one of the most common mistakes made. Whether IT or a line of business leads the effort, unless it has a committed executive sponsor with visibility and decision making power, the initiative is doomed from the onset. My colleague Clint Finch elaborated on this one in a recent blog post. We believe that this is the main reason why IAM initiatives that fail, fail.
6. Treating IAM as a project, not as a program - This is my favorite one, and at the risk of being controversial, I would say that this is the one plaguing the 2010's IAM initiatives. The issue is that even with executive sponsorship and a well-defined roadmap, without ownership, stewardship, continuity and context, the initiative will not achieve its goals. I applaud organizations that not only recognize the importance of this concept (many of which learned by trial-and-error), but embrace this by creating organizational structures that define the role of an IAM Program Manager (titles may vary of course). Having a senior leader, dedicated, empowered and motivated to make the program a success over a multi-year period is instrumental in the success of the IAM initiative. On this one, my argument is that the reverse is most often true: "treating IAM as a program, not as a project", significantly increases the chances of success for the initiative.
7. Too much, too soon - Managing scope is of course essential to any initiative to succeed, and IAM is no exception. What we believe is that an IAM initiative should be split into phases, and that these phases should not exceed 6 calendar months. Beyond that, we have seen organizations lose faith in the initiative, because it takes too long to derive value, which ends up draining the initiative. Each phase should have a meaningful scope with well-defined and measurable milestones that address prioritized business needs. Balancing what goes into each phase, how much is enough is of course critical, and highly dependent on the organization's business drivers. Empirically, there is something about the number "1200 person hours" that is consistent in successful IAM projects, so I tend to look for 1200 multiples to gauge how much goes into each phase. It is also very important here is to also consider the impact that the IAM program will have on end users - minimizing end user change will prove wise. Our CTO, Ash Motiwala, published an excellent 2-part series on scoping an IAM project (here is part I and part II), which are now our most read blog articles.
8. Not managing expectations for the dollars allotted - This one is perhaps a legacy of the 90's, when there was very little experience with IAM, and vendors ruled the world. So when a client had a budget set aside, most of the allocation would go into product procurement, leaving insufficient funds to fuel the end-to-end implementation of the solution. From there emerged "X factors", which became a way for clients to rank vendors - "vendor ABC's typical implementation is 3X the cost of license" or "I would go with vendor XYZ, since their TCO is about 5X the cost of license." We have improved in this area over the years, but the point remains: organizations need to set and manage the right level of expectation with their executive sponsors, and this is not just the cost to procure, architect, host and deploy the solution; but also the cost to operate and maintain it, as well as the impact that it will have on both the organization's applications landscape and end user training.
9. Not having the right team for the job - This pitfall is typical of the 21^st century, and in my view, the second most popular reason why an IAM initiative may fail. With deep specialization and over allocation of resources typical of today's organizations, having the right team is much more than just having the right skill sets and knowledge, and the right organizational structure, but it is also being clear on the resource availability. Even if you have the right people, but they are not available to devote time to the initiative, it will go nowhere. In our roadmap definitions, we spend time discussing our recommendations around the right structure to execute the work, and highlighting that there is a core team and a supporting roster. For example: an on-boarding or termination (provisioning and deprovisioning) project will go nowhere unless the appropriate stakeholders from HR are available to actively work on the project, particularly during the requirement analysis and design phases. Below is an example of an IAM initiative staffing structure we that we have recommended.
10. Poor technical architecture - This one is related to item 3 above, but it has more to do with the conception of the IAM infrastructure. There are choices that become very difficult to change or adapt later on if you have a poor technical architecture. There are no silver bullets here, and it's not like you can just decide to start from scratch and ignore what your IT environment already looks like. However, there are some questions you can ask yourself to validate your architecture:
• Am I leveraging the right tool for what it was intended? Are we using a meta-directory instead of a provisioning engine? Are we using a NOS directory when what we needed is an enterprise LDAP] directory?
• What if our company acquired another company or was acquired by another company? How would my IAM architecture adapt to something like that?
• What if we needed to change our [LDAP] directory schema? How would applications react to that? Would they need to be recoded?
• Are we wiring authentication into the applications, or is it being consumed as a service? What if we decided to move away from user name and passwords for authentication? Would we need to recode all the applications?
• How would this architecture scale over time both in terms of response time performance, administrative staff required to support it, and geographical coverage?

All right, there you have it. No parallels should be drawn between these and the David Letterman's top ten - or the Ten Commandments. Incidentally, I would really welcome somebody breaking down these 10 items ala George Carlin. Seriously though, your comments are always welcome.