Tom King is CISO at Lehman Brothers Holdings. He had a simple idea: rather than build authentication into each application, they would build a central identity. provisioning and authentication system. Three years later, he's still working on the project. Before he could implement his idea, he first had to create a single repository of identity information in the company. Why go to the trouble? Read the following paragraph from the CIO magazine article where Tom's story is told::

So why bother with identity management at all? Because the returns can be impressive. According to a survey of more than 7,500 top IT execs cosponsored by CIO and PricewaterhouseCoopers, the top two strategic security initiatives for CIOs during the next year are to block unauthorized access to systems and to monitor systems activity. Identity management systems can help you do both. They also let CIOs provide new employees with almost immediate access to the applications they need (and take away access from former employees just as quickly). And since authentication (you are who you claim) and authorization (you're allowed to do what you're trying to do) occur at one location, employees can access all their applications with a single user name and password, a move that can dramatically cut down help desk calls.

NerveWire found that 38% of the 145 companies it surveyed expected an ROI of as much as five times on their identity management investment, and another 10 percent expected even higher returns. In an age where ROI is the king of the hill, its no wonder that CIOs are tackling these project, even if they are long term.

Of course, identity management projects can get hung up and suffer from scope creep just like any other IT project. I think there are some keys to making sure this doesn't happen:

1. Realize that identity management isn't a product you can buy from a vendor. Its a process, that you have to create inside your business. This is about business goals, not just security or authorization.
2. With that in mind, do the enterprise architecture work around the identity management piece. By that, I mean that you need to work out governance, business needs, standards for interoperability, and infrastructure requirements.
3. Structure the project as multiple small projects. The first step is probably building a single master directory. The second should probably be password self-service since there's a huge ROI there for most organizations.
4. Require new projects to use the identity infrastructure and add onto it as needed. Bring legacy applications on board as it makes sense from a feature/functionality standpoint.

I should be very clear about the third point. If the only thing you want is the ROI on password self-service, that's an easier project than a complete identity management project. You can do it as part of an identity management project, however and bank the ROI gains to help defray the cost of the identity infrastructure.

The gains in this kind of project are often soft: better agility and increased alignment with business objectives. You should take ROI anywhere you can, but don't expect this to be a cold, hard numbers kind of decision.