The answer is simple; the level of involvement your business units will be required to give and the complete understanding of how their business processes operate in reality at the person level. In my experience implementing ERPs, global environments, SaaS products and IAM projects, these all share the attribute of business unit involvement, however not the amount which is required to make your identity or access management and governance program successful. With other projects, business unit (BU) involvement is limited to perhaps one or two stakeholders from key areas who can help gather requirements, define goals and steer the project. After the initial kickoff, these team members spend little of their time involved with either the consultants or the project proper until user-acceptance testing and production release. Not so when undertaking an identity or access governance project. Identity and access touches not just core stakeholders and users, but the very processes, workflows and ways people interact, with each other and the corporate technology stack, to complete their daily jobs. This difference cannot be understated nor treated in a cursory fashion. Many times, project sponsors underestimate the complexity of processes outside of their vertical. Other times, internal fiefdoms and politics can delay or even stop a progression; very often for very menial and solvable reasons. Most often, the business unit stakeholders did not have a clear understanding of what is involved when moving to a formalized identity and access management program. Finally, identity projects tend to be longer in duration, keeping organizational momentum is a Herculean task. So, if this is true, how can any identity project be considered more than a mid-grade success? As with everything, it starts with great planning. However the planning is subtly different. Sure, it shares the same buzzwords that can be used anywhere yet it is the substance of those buzzwords which is the making or breaking of a successful IAM implementation. Here are some of the key things that I’ve learned that should consider before launching your identity or access governance project: Socialization The simple fact of any new initiative is if the employee cannot see the value to their own day they have a hard time buying into the vision. Meeting not just with executive stakeholders from your partnering business units but also their key contributors within the unit will give a project sponsor an understanding and empathy for the unit’s perspectives and pains; not to mention motivations. Without this intimate knowledge and feeling for that unit’s goals and concerns, the project sponsor is sure to meet resistance during iterations when those needs aren’t met. Conceptualization Once you have done your internal due diligence through socialization, the next step is conceptualization and making it real to your stakeholder and project teams. This is where the real work begins. Our CTO and co-founder, Ash Motiwala, has a great series of articles on defining your identity management roadmap and steps to help prepare when scoping your IAM project. As you go through your conceptualization tasks, keep in mind the feedback which you learned through socialization and how that may be included with your selected identity or access governance system. Sometimes you will find that in order to accomplish both the needs of the project and the business unit you must find some compromise in a change to the existing business process or customizations of product at additional costs. It is also here you will learn of your risks and pitfalls. In understanding your HR onboarding and birthright provisioning, you may uncover the fact that you have tens of thousands of stagnant user and vendor accounts that should be imported to the new IAM system. If plans on handling situations like that aren’t created before the project begins, they could imperil delivery dates later. Finally, one of the most ignored items during conceptualization is what will be needed operationally to complete your project. Do you have a development and pre-production environment for use? With real-life test data in them? If not, plan for extended production testing, bugs and poor user reception since they’ll see errors when they begin using things. Do you have your team calendars synchronized and leveled to your goal delivery dates? Without leveling, there are ghost hours not accounted for and time which will extend the project dates. Are your data centers ready? Are your firewalls and federations in a state to communicate? All these details should be considered before your kickoff meeting. This article was original posted the Identropy Blog: http://blog.identropy.com/IAM-blog/bid/111096/Preparing-for-a-successful-IAM-integration-project-Part-1-of-2
