Mark Dixon is asking what some common success/failure factors might be for Identity Management projects.

To me, talking about success/failure of an IdM project is like talking about success/failure of a home plumbing renovation. Technically the project is a success once the water starts flowing — but the real story is in how long you went before you could take that first shower, how much $$ you had to lavish on the project, and whether you had to rip the drywall out again a week later.

I think the essential problem lies in the fact that IdM tools are built and sold on the strength of their ability to handle common, well-understood business scenarios, but the companies that try to implement such tools are messy conglomerations of systems and process with almost as many exceptions as there are rules.

My experience has been that the companies most likely to get into trouble are:

  • Companies with long & varied histories of mergers & acquisitions.
  • Companies with fractured lines of communication between different provisioning entities.
  • Companies with executives who *think* the business processes are straightforward but don’t take the time to dig any deeper.
  • Companies who are afraid or unable to take action when business process problems become evident during attempts to automate.

My strongest advice for companies starting IdM projects is: know your business processes and survey your repository content & structure to determine conformance to those processes before you try to assign a cost or a length to your project. Otherwise, what’s really happening is that you are giving your IdM project a bad rap – because they are having to perform both a business process audit and a technical implementation of the results all in one go, and when that happens, timelines slip.

Look at the small things – that is what will drag you down. Look at things like identifier life cycles across different systems, like identifier length limitations, especially on legacy systems, look at case sensitivity and encodings (ie Latin-1, UTF-8) of both names and identifiers across systems (especially mail systems, and even if you don’t believe that anyone in your company has a name that uses fancy characters), look at how geographically diverse your AD forest is and understand what the processes for choosing the fileshare that home directories & mailboxes get allocated onto, as well as whether those allocations or other business process decisions depend on departmental or locational data. If they do depend on departmental or locational data, is that data actually present in reliable format and in a consistent way from a data repository? This last question is CRITICAL – because if the only way a user gets placed on the right fileshare, or into the right groups is due to the fact that the person who enters the data into the system “just knows” where the right place is… well that’s tough to emulate in a system, and you had better anticipate a little consternation from the deployment team.

The bottom line is, garbage in, garbage out:

  • the complexity of your IdM project is directly related to the complexity of your business processes, especially those that are non-standard, or that have multiple originations.
  • the initial length & cost of your project will be related to how much/badly your company diverges from the common scenarios covered by IdM tools.
  • the likelihood that you will stay on-time and on-budget within that project depends on how close your initial understanding of the gotchas and exceptions are to the reality of your specific situation, and how good you are at forecasting what time will be needed to deal with all the things out there that you haven’t found yet.

Not that I have strong opinions on this subject or anything :-D