How do you mess up an identity and access project?

A "normal" customer visit for me is one in which I discuss how that customer can bolster an existing identity foundation, to provide additional protection, transparency, compliance, and administration. But there are two poles at either end of this. At one end, I've got customers who have little to no identity management. They're still doing everything manually, there is no central management of their many platforms, databases, and applications, and they couldn't tell an auditor under threat of violence or "The Best of Styx" what privileges any given user has.

At the other end are those customers who HAVE put something in place, and have done it so badly that they are looking to replace something that's broken or was never fully implemented. In some cases, they've got perfectly serviceable systems in place but which were not rolled out to completion. I remember asking one customer what was wrong with their deployment of one of my competitor's products, a producct they wanted to replace.

"We're still doing a lot of things manually," they explained.

"Why is that?" I asked.

"Because we never deployed the workflow," they answered.

This made me wonder, would they have any better success with MY stuff, if they didn't deploy MY workflow?

It's just one of a whole LOT of ways you can screw up an identity and access deployment. Wanna know what I think are the Top Ten Ways to Screw Up an IdM / IAM project? Well, I've actually created just such a list, and you can get it here:

http://www.identityaccessmanagementbook.com/download10.html

Have a look, and please let me know what you think. If you've seen other ways to achieve a broken or half-baked identity-access framework, I'd love to hear about them. This is not an excuse to wallow in other people's misery, but rather a way to suck all the mistakes out of the room, so that everybody going forward will get everything right. None of us is as smart as all of us. Except, of course, when my wife's relatives get together.