Identity Management Success Factors

In his post on Identity Management Success/Failure Factors, Mark Dixon asks:

Please send me your list of the five most important factors that contribute to the success or failure of Identity Management projects.

I know this is going against the grain, but I think the reports of wide-spread failure of Identity projects are grossly exaggerated. At least, troubled projects are no more prevelant in the IdM space than they are in relation to other technology projects. Technology for enterprise information management is inherently complex. But, I've been a part of a number of successful projects - their success measured by the feedback of the project sponsor at the conclusion of the effort. And I've spoken to a number of people in the field who tell similar tales. I only occasionally hear a real horror story about an IdM project. Usually those troubles are based on misaligned expectations or poor project management. That is, an executive sponsor expects a project to solve 100 problems, but the implementation only solves 50 and it seems like a failure. Or a development team tries to build a solution based on a half-baked design which keeps changing and there's no change control in place so the project quickly falls off schedule and over budget.

With those comments in mind, here is my list:

1. Establish clear and attainable objectives up front. This is vital. The only way to acheive success is to make the criteria for success clearly known and agreed-upon by all those involved. If this process is rushed or not clearly articulated, then there will be no consensus on the success of the project. While establishing criteria requires some knowledge of the business and the technology, this is primarily a perception issue -- not a business challenge and not a technology challenge. But, I think it deserves the #1 spot on the list.
2. Strong Project Management. The project manager is the person who establishes the objectives and manages the project toward those objectives. In a complicated project involving complex business and technology challenges, strong management is extremely important to keep things on track.
3. Build the Right Team. If the project requires interviews with business personnel, don't rely on a programmer and a DBA to deliver the project on their own. And don't expect a project manager to create a technical architecture. You need to understand the skills and roles required to reach your objectives as well as the capabilities of those on the team. Get the right team in place to cover all the roles. If the DBA is also a good business analyst, then maybe they can play two roles, but pay attention and spend the time and budget to build an effective team. I would also say that previous experience with the specific technology you're using would be great, but it's actually less important than having the right people in each role.
4. Have a Project Champion at the Right Level. IdM projects cross organizational boundaries and sometimes cross organizations. They tend to need executive sponsorship. The projects that were easiest for me to get through were sponsored by the CEO (or other business leader) and not only the CIO (or related technical folks). I was once working as a consultant interviewing a phone system admin for a provisioning project. During the interview, he asked if we had seen the movie Office Space because he felt like he was interviewing for his own job. This was, of course, not the case. But, it illustrates the importance of executive sponsorship. If it was the AD admin instead of the CIO that had brought us in, we may have had trouble scheduling time with this particular gentleman.
5. Build Cyclical Iterative Successes. Although I think the first four items are a sufficient recipe for success, if I had to come up with a fifth item that would make success more easily acheiveable, it would be to follow an iterative process rather than trying to do too much in a single project. Nothing builds momentum better than a few quick wins. In a large IdM rollout, this could mean having a project just to create an enterprise directory. Don't build the directory as the first step in the enterprise provisioning project but rather make the directory the result of it's own project. That success builds confidence amongst the team and the stakeholders. ...and divides up success into smaller, more easily measurable chunks.

There's definitely some overlap here with what Mark wrote. But honestly, I'd be more surprised if anyone presented a list that didn't have significant overlap. Thanks for the effort Mark!