As a Project Manager here at Identropy, I've been given the challenge and opportunity to share my thoughts and experiences with you regarding Identity and Access Management from the eyes of a Project Manager with on-the-floor experience. While Ash has shared his expertise regarding IAM roadmap development and how to determine if your company needs one or not, and Frank has shared his thoughts on the direction of IAM-as-a-Service and where it's going and how it's evolving, I'd like to spend a little time in these first posts talking about the "business" side of IAM.
Ideally, my life as a PM of an IAM project starts where the IAM workshop leaves off. I am handed the organized findings of the workshop that include business drivers, use cases/general requirements, a high level architecture and Identity Management roadmap. My first order of business is always challenging: to orchestrate interview sessions with client stakeholders in order to create an RTM, or Requirements Traceability Matrix. A good way to define stakeholders is to think through the processes that were defined in the workshop, and identify all the "touchpoints" throughout your organization, for example HR, Support Center, Desk-side Deployment, System Engineers, etc., and begin to involve them. (We also have a stakeholder definitions doc you might benefit from.)
For each of the interview sessions, prepare questions that can unearth (and differentiate) business requirements, functional requirements and technical requirements from the project stakeholders. It is absolutely critical to remember that the goal here is not to architect the solution, but rather to define just how big the elephant is. Don't let your organization be the blind man that defines the elephant based only on sensing the trunk or tail of the elephant.
For example, you might choose a self-service component of IAM to develop a use case that would walk through the process your end user will go through upon first logon after successfully being provisioned to a new LAN account. Using our first logon example, we would expect the Support Center would have requirements for the process related to delivery of the initial password, or perhaps what information is relayed to the user regarding Support Center services. We would expect that your HR department might have a requirement of the process that the user not be able to logon until they have been fully processed in the company's HR system. Perhaps your Information Security team will have requirements that place certain constraints on how your end users are initially provisioned to various target systems. Each use case that is developed to meet the needs of your business drivers will have requirements. These requirements should be listed in an RTM to include the requirement itself, the originator and/or owner, prioritization and general summary of what business driver it can be traced to and how it addresses this driver. As a note of suggestion, requirements should be as succinct and discrete as possible. IAM programs tend to have many moving parts, and tracing requirements necessitates that each requirement be a discrete element. Following this advice may balloon the overall number of requirements you have, but increase your visibility and traceability, which is extremely valuable.
The importance of an RTM cannot be overstated. It directly feeds your Work Breakdown Structure (WBS) and will be invaluable down the road in your IAM project as a guide to the scope of the program and who owns which requirements.
Lastly, I benefited from a few blog entries on the subject in the blogosphere I'd like to share:
10 Best Practices for an IDM Implementation by Mark Dixon
In our next discussion, we'll continue discussing the business aspects of an IAM solution and the pitfalls/roadblocks your company will need to look out for in order to increase your chances of a successful implementation.