So let's get this straight right up front

Identity Management is NOT all about technology

Good.

Technology is a set of tools that we can use to help us automate some of the business processes that exist within our organisations today. As Identity Management becomes a part of the fabric of our IT infrastructures, we may fall into the trap of trying to automate everything.

My first question to an organisation is "Who do you think will be affected by this project?" Note that I have not mentioned the "Identity Management" phrase in that question.  The answer I hear most often to this is "Oh, the IT department."  After another cup of tea (yes, I'm English!) and a little more discussion, the realisation usually kicks in that the business processes involve far more time for the non-IT staff.

Stakeholders

The choice of stakeholders and sponsors is an important one. These people will be helping to communicate the project back to the rest of the organisation and, in the case of the sponsors, ensuring that funds are available to keep the project going.

Any person who is currently involved in a business process that involves managing peoples identity within the systems involved could be a stakeholder. That's a long-winded way of saying "Everyone can be a stakeholder."

Now, of course we can't have everyone in an organisation involved on a project otherwise no core business processes would get done, so we take the normal approach of assigning representatives from line of business departments, IT (but only to a small extent in the initial discussions), and senior managers who normally act as project sponsors.

Apart from the IT guys who will make the technology do something (hopefully useful), there are administrators, data owners, testers, line of business managers, user and trainers and maybe some others who will need to be involved in the project and in the communications. More on resources can be found here. 

Expectations

Identity Management is not going to solve world hunger, the situation in the Middle East and increase the profits of the company four-fold within 12 months. Sorry, but that's the harsh reality folks!

OK, so I think I've got the message over - setting the right expectations from the outset is important. You should only be commiting to something that can be delivered in a reasonable timeframe (different for each organisation) and that will provide a benefit to the organisation.

Requirements

Suffice it to say here, a lack of clearly defined requirements can result in terrible project slippages and/or very uncomfortable relationships with suppliers, partners and internal staff. There is a whole page dedicated to requirements here.

Things go wrong ...

... and when they do it will be important to ensure that they are managed well. "Things going wrong" often includes the outcome of questions such as "can we also have this?" or statements such as "you're not allowed to put that data there." These are changes, or better known by project managers and IT people as scope creep.

The effect of things going wrong or scope creep can be minimised by good project management which includes a rigorously applied, well defined and previously agreed change control procedure. I cover more about this here.

I have been performing the role of Requirements Analyst/IDM workshop facilitator and been advising organisation about IDM for over 10 years. Please contact me if you would like some help.