Implementing Identity & Access Management solutions can be complicated. There are a wide range of features, technical inter-dependencies and business issues to be managed. Cost, schedule and scope issues can all result in project problems.
My first experience actually managing a large IAM project came in 2003. At that time the solutions were clumsy and the technical resources simply weren’t that strong. Today the product suites for IAM are much more capable, but there remain a number of risks to manage:
- Resourcing — Good people can be hard to find and you’ll want some good quality business analysts and at least one ‘go-to’ technical architect. Avoid resourcing risk by looking for these people early and once you get them in place, be sure to keep your core team happy. As you move along, try to cross-train the team members and document the solution — doing this will significantly reduce the risk to the project should a key person leave unexpectedly.
- Management Support — Don’t just give your boss a status report every week and think you’ve earned her support. Keep the communications flowing and be sure to celebrate successes and continually emphasize key benefits. Hit your dates, deliver as expected and people will notice.
- Technical — IAM’s complexity comes from integration, and while standards like SAML are well established, there is going to be customization required to get the solution working within an enterprise environment. With customization comes complexity and inevitable technical hurdles. Reduce project risk by tackling these head-on: identify the problem early and if the technical team is stumped, bring in the vendor experts.
- Scope Creep — Where possible, I try to keep the scope small to reduce complexity and to ensure the team delivers something every six months. If your scope does creep, it is on a smaller base of work and is much more obvious — and manageable. For bigger scope issues, communicate early and stop reporting ‘green’ status. If you don’t have clear scope you need to stop and resolve — don’t just assume you’ll fit it into the workplan. Another sure fire way to manage risk related to scope is simply to drop less critical functions. For example, if the scope creep is related to the administration component, perhaps drop the lower priority reports — they can always be built later, either as part of some follow-on project or by the operational support team.