Hitachi ID has a series of best practices out for deploying and operating your IAM solution. I think it’s worth your time to read. Here are the basics:
1. Engage stake-holders early and clearly articulate project deliverables, timeline and cost.
An automated IAM solution can affect a lot of different departments, according to Hitachi, so you should make sure to find out who would be affected and ensure they are onboard before you get the IAM project underway. Otherwise, you may find your implementation “disrupted” by an annoyed decision-maker.
2. Engage all stake-holders from the project’s inception, rather than deferring conversations with some of them until later in the project.
Don’t wait to bring those stakeholders onboard, as you will need to resolve their various disagreements with each other early on in order to increase the chances of a smooth implementation.
3. Engage executive-level sponsorship, to resolve conflicts between stake-holders.
Fairly self-explanatory. Get the highest higher ups who back your project to knock heads when particular stakeholders are being disagreeable with each other… or you.
4. Employ a full-time, technical resource from the start of implementation. This resource will assist in deployment and to manage the system in production.
Not only will the technical resource help you get the engineering right, but by using the same technical resource for operation as with implementation, you increase the chances of the techie being able to catch and resolve bugs early on, as well as making it more likely that the tech resource will be able to easily use the solution.
5. Engage a technical resource who will become the permanent system administrator of the identity management infrastructure in product selection.
See immediately above for the benefits to this arrangement.
6. Prioritize business drivers at the start of the project and focus on only the most urgent deliverables.
Why are you implementing the IAM solution, and for whom in your organization? Answers can include areas such as IT and regulatory compliance, IT support costs, and user service, according to Hitachi.
7. Establish metrics to support each business driver and measure results both before and after deployment.
Hitachi has a list of sample metrics you can check out in their document to help get your brain started.
8. Deliver functionality that is relevant to the business every 3–6 months.
This way you are always delivering something useful to various stakeholders, and thus keeping their support for your project.
9. Start long identity management projects with a rough outline of business priorities and milestones, and then Re-evaluate priorities after every one or two milestones.
Your business is constantly changing, and therefore your implementation plan might need to as well. Flexibility is key to thriving in today’s rapidly changing environment.
10. Defer detailed discovery and solution design for each phase until the team is ready to start implementing that phase.
That way, requirements, resources, and other important factors don’t change on you and render that beautifully designed solution irrelevant.
11. Start with small, simple deliverables. Work up to more complex functions and integrations.
That way, you build up the expertise of your implementation team. You also start to build momentum by putting some victories under your belt, which helps ensure support when you have to deal with the harder stuff down the road.
12. Plan for user acceptance testing, pilot tests, user awareness programs and user education.
Getting actual users to test usability can be invaluable to success. No solution will work if the users don’t want to use it, and find ways not to.
13. Organize a formal program to drive high user adoption for every user-facing component of the identity management system.
A good example is to give users a “one-stop shop” where they can handle all of their identity and access provisioning needs.
14. Provide a consolidated change request user interface and identify “implementers” to fulfill change types for which automation is not available.
Hitachi’s explanation: “Another side effect of engaging users is that they must be informed whenever the system changes. If a system changes often, this creates a flurry of e-mails in user in-boxes, which users learn to ignore. Too-frequent user notifications can act to defeat a user adoption program.
The need to keep users informed means that integrations with target systems should be grouped, so that users can be informed of new integrations less often, in a more meaningful way. For example, a quarterly e-mail about five more systems that have been brought into scope is more helpful than a weekly e-mail about another directory OU.”
15. To reduce user impact, implement multiple integrations at a time, rather than defining a project milestone around every target system.
From Hitachi: “The benefits of minimizing user announcements also acts as a counter-weight to the strategy of multiple, short deliverables. While it makes sense to define milestones every 3 to 6 months, it does not make sense to subdivide a project into weekly or monthly deliverables.”
The best practices worksheet also has a step by step outline and timeline for implementing an IAM solution below best practices, so take some time to check it out if you are working on an IAM solution right now.
Doug Atkinson
An entrepreneur and executive with a passion for enterprise technology, Doug founded Solutions Review in 2012. He has previously served as a newspaper boy, a McDonald's grill cook, a bartender, a political consultant, a web developer, the VP of Sales for e-Dialog - a digital marketing agency - and as Special Assistant to Governor William Weld of Massachusetts.
- Yahoo Goes Passwordless to Access Account Services - April 6, 2015
- The Identity of Things Could Streamline Government Services - March 30, 2015
- The Third-Party Threat: Are You Safe? - March 18, 2015
