Blog

Top 10 Common Pitfalls of an IAM Initiative

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.

On Developing an Identity Management Roadmap, Part III

In part 1 and part 2 of the series on roadmap development, we covered scenarios where you should not develop an IAM Roadmap and some of the prep work towards developing one.  In this entry, we'll cover the actual steps of working out a roadmap.  Hat tip to Luca, who left a comment on part 1 of this series which helped provide some direction for this blog post.  Luca asked:

How can a long-term road map help to achieve a good outcome (architecture, software, finance) in highly dynamic environments? In your opinion, is it possible to put down a road map that can be useful even after plenty of mergers and reorganizations? I am wondering if is possible to define a road map that could be, in the same time, enough flexible, to be respected also after some important changes, but well defined, in order to be useful and drive choices in the right direction.

My short answer to the question is, yes, I do believe that it is possible to develop a flexible roadmap that can weather the storm of environmental changes. The core is to approach the development of your roadmap using a proven and agile methodology (we at Identropy have developed our roadmap development methodology). But before we get there, a little background information is in order.

An IAM roadmap should consist of multiple phases or iterations, where discrete use cases are implemented in each phase.  Each phase should have an average duration of 3-4 months --, slightly shorter or longer is acceptable, but we try to never exceed 6 months at a time; and identifying 'Lessons Learned' and a 'Roadmap Review and Adjustments' exercises between phases is critical. You cannot assume that the roadmap is static, it needs to be adjusted and recalibrated.  The total duration of the roadmap should range between 12-36 months. Beyond that timeline, your roadmap starts to lose touch with reality and its value diminishes.

The following is our 5-step process for IAM Roadmap development:

1. Assemble the Building Blocks (Use Cases)

 The building blocks of any roadmap are the identity initiative use cases that you have already identified as important for your organization.  Furthermore, each use case should be related to a set of requirements.  All of which must have been developed prior to roadmap development, as described in part 2 of this blog series.

2. Discover Roadmap Placement Criteria

Roadmap Placement Criteria are meant to serve as a guide towards placing a use case in a specific phase within the overall IAM program.  Our fixed criteria are 3, and are seen in almost every identity management program:

• Value: How valuable is this use case to the organization?  Many times, this is directly related to who the use case is important to within the organization. For example, if the CEO has a directive that the use case addresses, then its value to the organization will be greater than that of a use case that addresses a departmental need, not directly aligned with the critical path of the organization.      
• Complexity:  How complex is it to orchestrate the completion of this use case? Complexity should not be viewed from a purely technical perspective, but as a whole – is there a capital investment required? is the organization ready to undertake the initiative? does it have the right resources and change management approach? is there executive sponsorship and organizational alignment to make it happen?. For example, most Identity Provisioning projects today are not terribly complex from a technical perspective, although they can quickly become complex due to political reasons.
• Dependencies:  Does the use case require that another use case be completed prior to addressing it? Is there a logical progression for tackling the use case that makes sense to sequence?  This could be an architectural dependency (which it often is), although it could take a broader meaning. For instance, you may address a smaller-value, but related use first to build momentum, credibility and build experience and confidence, which will help you undertake the higher-value use case – in a way “walk before you run”. Other factors may be taken into consideration based on the organization's priorities, such as  timeline dependencies (for instance based on compliance-driven deadlines) or specific “quick win” use cases.

 

3. Create a Roadmap Analysis Diagram

Once you have identified the use cases as well as the criteria, you will need to create a roadmap analysis diagram that displays the information in a consumable format.  By placing all relevant information in a single diagram can be instrumental in forging meaningful dialog towards developing a roadmap.

In the diagram above, we've kept it simple by representing the 3 main criteria: complexity, value to the organization and dependencies. Complexity is represented on the x-axis, value on the y-axis, and dependencies as arrows between use cases, which are represented by the green boxes. You could extend this chart as needed to accommodate additional criterion as appropriate (for example, by adding a z-axis, but we tend to get lost after the third dimension).
Placement of use cases (green squares) in the correct place on the chart can be a tricky endeavor, and should generate fruitful debate among stakeholders. The particularly challenging part of this exercise is to have a fair degree of consensus of the relative value and complexity that the organization assigns to each use case. Clearly, this will vary greatly for each organization, and hence why there is no “cookie cutter” approach to an IAM roadmap.

Advice: A good piece of advice that our clients have found useful is to start with extremities (the most and least valuable, mostand least complex), and place all other use cases on the chart relative to those. We typically iterate a few times through this chart before we discuss it with a broader audience. Additionally, we suggest that you start with two dimensions first, say value and complexity, before you factor the third dimension, say dependencies.

 

4. Translate the Roadmap Analysis Diagram into an Implementation Plan

 By taking the information gathered during Roadmap Analysis, use cases can be intelligently placed in different "buckets" that represent a phase. Which once defined and sequenced, will become your Implementation Plan.  Phase 1 should consist of foundational components that can be quickly identified from the Roadmap Analysis Diagram by singling out use cases with multiple arrows pointed towards it, without any arrows emerging from it – this is a good way to identify your “quick wins”.  Phase 1 should be relatively rich in “quick wins”, or use cases that have no dependencies and fall in the top left quadrant of the Roadmap Analysis Diagram: lowest complexity, highest value. Analyzing dependencies should also provide insight into parallel vs. serial execution/implementation of use cases.

 

Advice: Each phase should last an average of 3-5 months.  Since the success of your IAM program is so heavily dependent on incremental wins in order to build momentum, as well as feedback and lessons learned, anything longer than that should be broken down into sub phases.  Two 3-month phases are almost always better than 1 6-month phase. Also, at present times, we believe that any Implementation Plan that extends further beyond 24 months becomes unrealistic, and there is no use in forecasting activities that far out, since the pace of changes will undoubtedly invalidate most of your assumptions, not to mention the pace of technology evolution may provide different options to achieving the objectives.

 

5. Vet Results with Executive Stakeholders, and Get Their Support

Once completed, vetting the roadmap with executive stakeholders is critical. An executive stakeholder can provide valuable insight that will better align the roadmap to the organization's drivers.  During this exercise, demonstrating your thought process is as important as the actual roadmap that you've arrived at.  Expect it to be altered. In fact, be disappointed if it isn’t.  But, if you fail to provide a framework for executives to think within, alterations can break the overall approach you've spent so long thinking through.  Here are a few questions you'll want to have answers to for before this session:

• Can we complete this roadmap in less time? Perhaps by adding more resources?

• Can I implement a specific use cases earlier if necessary?

• Can implementation costs be reduced by executing 2 of the phases in parallel?

• What risks do I face for stopping after a specific phase and taking a break until the following year?

Spending up-front time constructing the right framework for your organization during the roadmap development exercise will prove invaluable to your efforts in the long run.  It will allow your organization to be flexible and make informed decisions (instead of reactionary responses) to the cross paths that lie ahead. At the same time, by having the executives engage in discussions and revisions of the roadmap, your chances of securing their support (and thereby securing funding) drastically increase. In another blog series, we will talk about the most common pitfalls in an IAM initiative, and not having executive sponsorship is perhaps the “kiss of death” for any IAM initiative. Hopefully, this series has provide you with enough tools and confidence to navigate your path, but we do recognize that every organization is different and there are externalities (such as a recessed global economy) that will greatly impact an IAM initiative, regardless of how well your IAM roadmap had been developed, but to quote the great Wayne Gretzky: “you miss 100% of the shots you don't take.”    This concludes our 3-part series on Developing an Identity Management Roadmap.  We hope you've enjoyed it, and look forward to your comments...

On Developing an Identity Management Roadmap, Part II

In Part I of this series, we covered why a corporation may (or may not) need an Identity Management Roadmap. In this post, we'll briefly cover its prerequisites.

Roadmap Development should be viewed as a discrete task that is only one component of an Identity Management Workshop. In fact, Roadmap Development should be the last (or one of the last) tasks in your identity management assessment. Here is a brief description of a few items that you should have explored during your workshop prior to the task of Roadmap Development:

1. Drivers

Your organization's business drivers for the IAM (Identity & Access Management) initiative will set the overall tone of the workshop, and should be the first item you discuss. Based on a detailed discussion of the drivers, an Identity Initiative Definition document should be drawn up, that labels your drivers, and a brief paragraph that explains each one and how it relates to your initiative. For example, a business driver may be "Acheiveing Compliance to XYZ Regulation", where the description describes why its important to your organizatoin.

2. Use Cases

For each driver, a set of use cases should be developed that explains in human readable language, the scenario you are facing, and a description of the expected behavioral response of the identity management system.

3. Business Process Analysis

Business Process Analysis is probably a heavy term for what needs to be accomplished here. Part of the Identity Management Scoping Exercise will identify all processes, user populations and target systems in scope. An analysis of the in-scope processes should occur in order to measure complexity of any process re-engineering and technology mapping efforts.

4. Technical Infrastructure and Competency Analysis

A survey of the current infrastructure will provide insight into the complexity of integrating an IAM solution, as well as the assets currently owned by your organization that may be leveraged as a part of the solution. During our workshops, we often find clients own more than they know - a finding that saves significant software dollars.  Also, an assessment of your organization's technical competencies is important, in order to take training prep into consideration during roadmap development. 

5. A Proposed Logical IAM Architecture

By creating a suggested logical IAM architecture prior to creating a roadmap, your organization will unearth technical dependencies between the various components of your identity management solution - a key finding that will inevitably impact how you lay out your roadmap.

 - - - - - -   

Hopefully the points above have elucidated why an efficiently orchestrated Identity Management workshop will not dive head first into the tricky task of Roadmap Development. A lot of prep work has to be completed in order to lay the right foundations for the task. In the next section of this series, we'll focus on the actual tasks of developing a roadmap.

Managing IdM, Unique or Just Plain Vanilla

I recently read a number of posts where managers were fighting it out about how unique an Identity Management Project really is and sometimes I truly think that people forget that this is an Enterprise Implementation with many diverse moving parts. Dealing with an entire enterprise no matter how small the subset of users brings a large number of difficulties that could lead even the best of project managers to lose their hair. 

The most successful managers have a combination of soft skills, analytical skills revolving around business process management and a high level understanding of security and directory technologies. Some would consider these skills plain vanilla but when you disect each deliverable sometimes being dependant on so many areas which you have no control over and the task of plotting out deliverables such as connector development which will have end user visibility only when workflows or other features are in place leads me to think otherwise. These constant transitions could be quite tricky and from the way I see it could be considered quite unique.

In a nutshell the conclusion on all of the posts was that IdM Projects are unique but so are projects in other industries.  Basically paraphrasing an old saying..."if you have to ask how much something costs you probably can't afford it" just the same as if you have to ask why an Identity Management Project is unique...

Identity Management Project Scoping, Part II

In my last entry on Identity Management Project Scoping, I wrote about putting together a "PUT" chart, and creating Business Process Correlation sets. If you have been following along, at this point you should have a pretty telling matrix of processes, user populations and target systems, along with correlations and priorities.

Here is the next step...

Step 3: Provide a Non-Technical Description of Each Process

This one could be a bit time-consuming, but well worth it. For each Business Process Correlation Set, provide a short non-technical description of the process flow from beginning to end. For a more detailed method of describing the workflow, create a table that follows the template below (a sanitized example from one of our clients):

...

 At the end of this excercise, you should have a pretty good handle of what business processes you are looking to automate, the target systems, the user popuations, the priorities, and a good grasp of the process as it stands today.

Typically, the total set of data that you have completed will need to be broken down into a phased implementation.  An Identity Management Consulting firm should be able to guide you in the process of translating the results of the scoping excercise above into an Identity Management architecture, help you find a solution that works for your specific requirements, as well as help you put together your very own Identity Management Roadmap (yipee!).  All fun stuff, and good practice when engaging in an Identity Management project.